Doesn't integrate with Views

The fastest way to tell is to look at the actual SQL query views generates in he 'preview' section of the Views UI. If it's working properly, it should have some chunks of SQL like the ones below:

You might also try adding an actual display field for the 'Value' or 'Function' to a Table view, so that you can see what information is actually in the fields that you're sorting on. "Function", for example, usually just contains the word 'average' or 'sum' -- and since you're already filtering that to 'average' in the relationship itself, sorting on the field won't actually change the order. Every record, after all, will be one that has the word 'average' in that field.

I second this.
since updating to the latest version of views and/or voting API, votingAPI no longer works with views no matter what i try.

the chunks in the preview area involving votingAPI are there, but it doesn't work.
if the votingAPI relationship is set to "required" then it displays nothing.

You'll need to give me some information about how you configured the view, and the relationship itself. In addition, it would be useful to know what information is actually there in the votingapi_votes and votingapi_cache tables; is there actually any data for it to display?

An export of the view would be particularly useful.

Sure. probably should have thought of doing this originally...

I just made a view that has nothing really except for a relationship to voting API 'voting results.'
it displays nothing. but i do have things with votes, of course.
i checked the votingAPI_vote and votingapi_cache tables and they had stuff. i even cleared them out and recast a bunch of votes from multiple users to no avail.

i've tried with various other setups for this view, (including the one that was working fine before upgrading to either the newest release of views or the newest release of voting API. i updated them both at the same time.)
i've tried all (i think) of the relationships and mixes of sort criterias and fields. nuthin...

Here's the query:

SELECT node.nid AS nid,
   node.title AS node_title
 FROM node node 
 INNER JOIN votingapi_cache votingapi_cache_node___average ON node.nid = votingapi_cache_node___average.content_id AND (votingapi_cache_node___average.content_type = 'node' AND votingapi_cache_node___average.value_type = '' AND votingapi_cache_node___average.tag = '' AND votingapi_cache_node___average.function = 'average')
 WHERE node.type in ('article')

and here's the export:

$view = new view;
$view->name = 'toprated';
$view->description = 'Top Rated Articles';
$view->tag = 'tops';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('relationships', array(
  'votingapi_cache' => array(
    'label' => 'Voting results',
    'required' => 1,
    'votingapi' => array(
      'value_type' => '',
      'tag' => '',
      'function' => 'average',
    ),
    'id' => 'votingapi_cache',
    'table' => 'node',
    'field' => 'votingapi_cache',
    'relationship' => 'none',
  ),
));
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Override',
    ),
  ),
));
$handler->override_option('filters', array(
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'article' => 'article',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'relationship' => 'none',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
  'role' => array(),
  'perm' => '',
));
$handler->override_option('items_per_page', 5);
$handler = $view->new_display('block', 'Block', 'block_1');

any help would be much appreciated.
thanks.

(i just hope i'm not doing something dumb...!)

thanks again,
-Kevin

Aha! Two things jump out:

First, you just uncovered a bug. It looks like you didn't choose any restriction for the 'tag' and 'value types', so they shouldn't be part of the join query at all. Instead, they're showing up empty. That didn't show up in some of the earlier testing, and I'll need to roll a fix for it today.

The second issue though is obvious from looking at the query -- you've added the relationship, but not added any fields, sorts, or filters to the view itself, just the 'Node title' field. Adding a relationship in Views just establishes a 'link' between the base table that you're displaying, and some other pool of information (in this case, VotingAPI's records). You need to first add the relationship, then add a field, sort, etc.

Given the bug that I mentioned first, you'll also need to specify a tag, value_type, and function for the relationship. That's almost always desired anyhow, though -- if you don't specify some restriction for them, it's easy for multiple records to show up in the view for each node. I'll try to write up some more comprehensive docs shortly.

Thanks for the suggestion.
I really appreciate the swift responses!

So i tried it out with a brand new view adding the relationship first, then adding fields, filters, sorts, etc. something's still going wrong.

if the relationship is required it displays nothing. if i put a votingAPI function field (labeled "average vote:") in and set the relationship to be not required, it displays lots of nodes, but the average vote field is blank. it just says "average vote: ".

as before, i hope i'm not doing something silly here...
perhaps i'll try dropping the voteingAPI tables entirely and reinstalling the votingAPI module to see if maybe i've bugged myself up somehow...

here's the query:

SELECT node.nid AS nid,
   node.title AS node_title,
   votingapi_cache_node_points__average.function AS votingapi_cache_node_points__average_function
 FROM node node 
 LEFT JOIN votingapi_cache votingapi_cache_node_points__average ON node.nid = votingapi_cache_node_points__average.content_id AND (votingapi_cache_node_points__average.content_type = 'node' AND votingapi_cache_node_points__average.value_type = 'points' AND votingapi_cache_node_points__average.tag = '' AND votingapi_cache_node_points__average.function = 'average')
 WHERE node.type in ('article')

aaaaaand here's the export:

$view = new view;
$view->name = 'topvoted';
$view->description = 'Highest average vote article';
$view->tag = 'tops';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('relationships', array(
  'votingapi_cache' => array(
    'label' => '',
    'required' => 0,
    'votingapi' => array(
      'value_type' => 'points',
      'tag' => '',
      'function' => 'average',
    ),
    'id' => 'votingapi_cache',
    'table' => 'node',
    'field' => 'votingapi_cache',
    'relationship' => 'none',
  ),
));
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
  ),
  'function' => array(
    'label' => 'Average vote',
    'exclude' => 0,
    'id' => 'function',
    'table' => 'votingapi_cache',
    'field' => 'function',
    'relationship' => 'votingapi_cache',
  ),
));
$handler->override_option('filters', array(
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'article' => 'article',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'relationship' => 'none',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
  'role' => array(),
  'perm' => '',
));
$handler = $view->new_display('block', 'Block', 'block_1');

thanks

Yeah, I don't think I was clear enough in my earlier message that there is currently a bug in the join handling for the relationship: when you create the relationship for VotingAPI, you must choose an option from each of the dropdowns in the relationship form. In the example that you exported, there was no 'tag' selected. If you take a look at the SQL query that's being built, that results in a "WHERE tag = ''" being added to the query; that will filter out ALL results, since every vote and vote result has its tag set. Try choosing 'Vote' for the tag, save the relationship, and all should be well. There will be an updated version of VotingAPI that fixes that bug coming out this weekend, hopefully.

Just a heads up that the bug I mentioned is now fixed in the CVS version of VotingAPI, and should be part of the -dev snapshot in an hour or two. Once that's in place you should be able to use any funky combination of relationship restriction criteria you desire. ;-)

Okay, got it working now.
I had tried all sorts of variations (including using all those filters), but it still didn't work.
What got it working was using percent instead of points. points didn't work.
is that because of me, or is that because of votingAPI?

'points' versus 'percentage' is really about what KIND of votes are being stored in your database. For example, the popular Fivestar module stores its votes as percentages while the Vote Up / Vote Down module stores its votes as points. Both of those modules can co-exist on the same site, even casting their votes on the same node at the same time. When you create a relationship, and choose which kind of value_type you want to be a part of that relationship, you're telling Views which of those two 'bins' full of votes you want to include.

One of the reasons this system was set up was for increased flexibility. If you have both of those modules installed, for example, you can create one relationship for 'points' votes and another for 'percentage' votes, then make a view that lists for the 'number of points' users have assigned to a node with Vote Up/Vote Down, AND the average rating that people have given to the same node with Fivestar.

It can be a bit confusing sometimes, as most users only have one module installed at the same time. If there are any ideas on how to simplify this process, please drop me a line; I'd love to iron out some simplified approaches as long as they don't break some of the edge cases that the relationship mechanism was designed to facilitate.

The bug that you encountered has been fixed and should be rolled into the next dev release. Thanks!

This issue exists in the 5.x version as well. My Views are breaking because of the JOIN posted above. Here is the error.

Unknown table 'votingapi_cache_vote_percent_average' in field list query: SELECT node.nid, node.title AS node_title, node.changed AS node_changed, uc_products.sell_price AS uc_products_sell_price, votingapi_cache_vote_percent_average.value AS votingapi_cache_vote_percent_average_value, node.created AS node_created, ... etc