Currently, votingapi does not expose a view definition that allows show all votes, filter all votes by user_id, etc. The supplied patch adds a 'votingapi_vote' table to the votingapi_views.inc table definitions.

This table is an inner join against the node table. This approach is similar to how comments are handled creating a row for each node-vote relationship. This table is largely a copy of the existing table definitions, so it includes fields for values, user, etc. It does not currently have fields/filters/sorts for tag and type. Those these would be easy to add.

This also includes an argument to filter the results by uid. So we can display a list of nodes voted on by a specific user. This patch does not obviate the uses of the specific tag type views tables, but does provide some functionality not found in the existing set up.

Enjoy

CommentFileSizeAuthor
votingapi_views_general_table.patch5.09 KBmfredrickson

Comments

eaton’s picture

eaton commented
Status: Needs review » Closed (works as designed)

VotingAPI 1.x's views integration is rather jacked up, inherently. I'm very hesitant to pour more work into it as 2.x only fixes the issues by relying on more flexible Views 2 API features.

If anyone's interested in working on a backport of some of the new approaches from the Drupal 6 version, or in working on a 'better' implementation of Views integration for Drupal 5, please contact me directly; I'm interested in a co-maintainer.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Category: feature » task
Status: Closed (works as designed) » Active

Well, this is what I was searching for finally...
The triple'd foreach type/tag views tables bloat in votingapi_views.inc is most likely the cause for several performance issues with Views. We are currently struggling with a 1,2 MB views_tables cache blob which is probably the cause for various MySQL server connection errors (max_allowed_packet size, MySQL server has gone away, aso.), because this cache (among others) needs to be loaded and transferred from db to www on each and every page request. Without having hard numbers, I'd guess that VotingAPI's views tables take up to 40-50% of this cache alone.

If you plan to drop support / efforts on 5.x-1.x, I'll just hack my copy now (and hope that this issue no longer exists in D6 and we'll upgrade this particular site to 6.x at all...)

eaton’s picture

eaton commented
Status: Active » Closed (won't fix)

Support for the 5.x branch of VotingAPI has ended with the release of Drupal 7 and the upcoming release of VotingAPI 7.x-2.4.