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
Comment #1
omnyx commentedis it really true that votes remain?
Comment #2
markus_petrux commentedTry the following queries and see for yourself.
Also, check with comments.
Comment #3
tj2653 commentedI'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.
Comment #4
eaton commentedVotingAPI 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.
Comment #5
markus_petrux commentedSorry for reactivating. I believe this issue should be reconsidered.
A couple of examples:
advpoll: This module has the following code in hook_delete():
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
Comment #6
eaton commentedTo 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.
Comment #7
markus_petrux commentedOk, 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
Comment #8
eaton commentedPlease re-read what I've posted in this thread. You seem to be missing a couple of important points.
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).
Comment #9
markus_petrux commentedThough 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...
Comment #10
alliax commentedThis 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 :
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,
Comment #11
Scott Reynolds commentedComment #12
alliax commentedThank 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.
Comment #13
seandunaway commentedFor 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
Comment #14
alliax commentedthank you rump, could you add a button in your module so that we can delete all votes from previously deleted nodes/comments?
Comment #15
seandunaway commentedHey alliax,
Check out version 2.3. I just pushed up some 'delete existing orphaned votes' functionality!
Comment #16
alliax commentedThank 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 :-)