When content is removed, related votingapi information is not deleted.

Maybe votingapi ought to hook into (at least) nodeapi/commentapi, or maybe provide a votingapi method to easy the task to modules using votingapi, so they do not need to know how votes are stored, or how to remove them when related content is removed.

Comments

omnyx’s picture

is it really true that votes remain?

markus_petrux’s picture

Try the following queries and see for yourself.

#
# nodes that were deleted still present in votingapi_vote table
#
SELECT v.*
  FROM drupal_votingapi_vote v
  LEFT JOIN drupal_node n ON n.nid = v.content_id
 WHERE v.content_type = 'node'
   AND n.nid IS NULL;

#
# nodes that were deleted still present in votingapi_cache table
#
SELECT v.*
  FROM drupal_votingapi_cache v
  LEFT JOIN drupal_node n ON n.nid = v.content_id
 WHERE v.content_type = 'node'
   AND n.nid IS NULL;

Also, check with comments.

tj2653’s picture

I'm having the same problem...any votes associated with a node and the comments in the node are left in the database after that node has been deleted.

eaton’s picture

Status: Active » Closed (works as designed)

VotingAPI does not actually touch nodeapi, userapi, or any similar functions. Because numerous modules may be inserting data in its tables to a number of reasons, it only deletes data when explicitly told to. Modules that need that data purged should unset the votes themselves, or delete them and manually trigger a recalculate for the deleted content to flush the cache values.

markus_petrux’s picture

Status: Closed (works as designed) » Active

Sorry for reactivating. I believe this issue should be reconsidered.

A couple of examples:

  • advpoll: This module has the following code in hook_delete():

      // TODO: These should be converted to a votingapi method eventually.
      db_query("DELETE FROM {votingapi_vote} WHERE content_id = %d AND content_type = 'advpoll'", $node->nid);
      db_query("DELETE FROM {votingapi_cache} WHERE content_id = %d AND content_type = 'advpoll'", $node->nid);
    
  • fivestars: This one simple leaves orphan votes when node is removed.

IMHO, advpoll comment is pointing the same issue that I have reported here. Otherwise, one needs to do this by hacking into de voting_api tables.

Sure there's an api to remove one single vote, though it might make things easier if there was an api to delete all votes related to one particular content type.

I mean, voting_api does not need to touch nodeapi, but it could provide a door to make things easier for module developers.

I hope you can get the point better.

Thanks

eaton’s picture

Status: Active » Closed (fixed)

To clarify, VotingAPI 2 provides batch deletion and cleaner batch selection -- the votingapi_delete_votes() and votingapi_delete_results() functions provide just the functionality you're describing.

I don't really have the bandwidth to maintain two evolving versions of the API, and this specific case, where the current otion is to simply write one line of SQL, is not that troubling. Hacking the VotingAPI tables" is a misnomer -- the entire purpose of VotingAPI is to provide a consistent, reliable data storage schema for votes and results. If some modules manipulate the schema directly, I have no problem with it.

markus_petrux’s picture

Ok, you should have started with that. Hence, you don't hace the time (or don't want for whatever reason) to add something like votingapi_recalculate_results($content_type, $content_id) to remove any votes when content is deleted, forcing developers to hack into the voting api database, even if that compromises maintenance of 3rd party modules, "you have no problem with that". 10 points for you.

Have a nice day

eaton’s picture

Ok, you should have started with that. Hence, you don't hace the time (or don't want for whatever reason) to add something like votingapi_recalculate_results($content_type, $content_id) to remove any votes when content is deleted, forcing developers to hack into the voting api database, even if that compromises maintenance of 3rd party modules, "you have no problem with that". 10 points for you.

Please re-read what I've posted in this thread. You seem to be missing a couple of important points.

  1. Because many modules insert data into VotingAPI tables for many reasons, assuming that votes should always be deleted when a node is deleted can result in unintentional data loss.
  2. A wrapper function whose only purpose is to delete all votes and vote results for a specific piece of content is, potentially, something that could be useful. As I mentioned in my previous post, however, it would be a 'no-op', replacing two calls to db_query() to two calls to VotingAPI.
  3. Running a SQL query against a documented data schema is not 'hacking the database.'

In VotingAPI 1.0, there have already been numerous complaints from developers complaining that too much data is automatically 'wiped out' by assumptions about how modules will interact with each other. (For example, clearing out all 'percentage' votes, regardless of tag, when other 'percentage' votes are cast using the wrapper function).

markus_petrux’s picture

Though the result of that is advpoll devs have a note in their code that an API to drop votes from a node would have been nice, and fivestars simply leaves orphans (unnecessary bug on their side).

Voting API does not need to hook into nodeapi, userapi, whateverelseapi, ... but it would be nice if it could offer a method to delete votes from a particular content_id.

I could have reported an issue to the fivestars module. But if such an API existed, it would haven't been necessary, probably. Or at least easier to report. I haven't looked at other voting api related modules, so I'm not sure how many of them have this same problem. If that was the case, I believe reporting the heart of the problem benefits all of them, even if that makes me look annoying.

Keeping an eye on how 3rd party modules use the API (or better, how they need to access data directly) could give some ideas on how to improve the heart to make things easier in the future. What if for whatever reason the database schema needs to be changed? If one needs to access the underlying database schema to do something, then it looks like a sympthom that the API is incomplete, but hey, what do I know...

alliax’s picture

This is very important for me because I have so many votes in my database, I have deleted a lot of posts and the votes are still in the database. I tried to modify the original query in #2 :

DELETE
  FROM votingapi_vote v
  LEFT JOIN node n ON n.nid = v.content_id
WHERE v.content_type = 'node'
   AND n.nid IS NULL;

But this is returning a syntax error. When I run it as a select as in the original, I have the correct result, but I'd like to delete them all with such a query.

Cheers,

Scott Reynolds’s picture

DELETE v
  FROM votingapi_vote v
  LEFT JOIN node n ON n.nid = v.content_id
WHERE v.content_type = 'node'
   AND n.nid IS NULL;
alliax’s picture

Thank you very much for the corrected query, I've found I've also the same problem with table TERM_NODE after deleting many orphan terms (not used by any node anymore)
The term node is not being cleaned when the delete term function is being used.

This other problem is totally unrelated to Voting API, I'm just saying that I encounter the problem in other aspects of Drupal's modules.

seandunaway’s picture

For others stumbling on this thread looking for answers:

I threw together a quick module which deletes the votes for nodes and comments. I hope to add support for other entity types soon.

http://drupal.org/project/votingapi_autoremove

alliax’s picture

thank you rump, could you add a button in your module so that we can delete all votes from previously deleted nodes/comments?

seandunaway’s picture

Hey alliax,

Check out version 2.3. I just pushed up some 'delete existing orphaned votes' functionality!

alliax’s picture

Thank you, it works!
I wish there was a 5.x version, yes I still have a site in Drupal 5 and the task of updating seems impossible to me, too many things going on I'm sure an update to 6 will be unsuccessful.
I'm not asking you if you're going to do one, I know Drupal 5 is not supported anymore, it was just wishful thinking :-)