Posted by Artem on March 24, 2007 at 9:23am
Hi
I am thinking about tuning my vote_up_down based site into a bit more digg-like site. On Digg 50 votes per hour can outperform 500 votes per two weeks - it allows "hot" news to be pushed to the front page earlier. Can similar things be achieved with the help of voting_api?
- I am thinking about attaching to every node, not only a "vote" counter, but also kind'a "internal priority" counter, that would be increased by user votes and decreased by time therefore making old votes less valuable.
- Then whenever user votes on some node, that node's "internal priority" will be compared against the "internal priorities" of the current front page items. If newly voted node's "internal priority" was bigger, it would be promoted to the front page.
2.1 Since "internal priority" directly depends on time and needs to be known for the front page items only, it can be updated on demand, so that you wouldn't have to update "internal priority" of all the 20000 site nodes every hour.
Is anything like the above scenario possible with the voting_api? If it is not possible immediately, I am not afraid of some PHP programming to make it possible. However, I am rather new to the Drupal's voting area and I'd very much appreciate some pointers on where to start and how complex the task could be. Could anyone give an advise?
Best regards,
Artem.
Comments
doable with a custom function
this is exactly what hook_votingapi_calculate is all about. ;-)
When you retrieve the 'average' and 'count' results for a vote, you're just pulling up records that votingapi populated by default. It's totally possible to hook into the recalculation process and add another bit of data: 'velocity'. Since every vote record has a timestamp associated with it, you could loop through them and apply whatever calculation you'd like to, and add a 'velocity' record to the results collection before it's saved to the votingapi_cache table. Voila -- all your views become sortable by velocity, etc.
Would that work?
It would "almost" work since
It would "almost" work since I want the kind'a "effective vote" of the currently voted item to be compared to the effective vote of the other front page items and those should decay over time.
How I solved it for S60 Applications is that I invented two metrics timedPriority (votes - number_of_hours_since_first_vote*some_factor) and timedPriorityOverFrontPageItems. The first one is forced to be recalculated every cron run but only for the first 20 front page items (not to do it for all 10000 nodes). Then timedPriorityOverFrontPageItems is the timedPriority of the currently voted item - minimal timedPriority of the first 20 front page items.
Whenever timedPriorityOverFrontPageItems is > 0, item gets promoted.
As you see, the main problem I had is not with the formula, but with:
1) the fact that the "other" item votes have to depend on time.... or maybe I could have solveed it simpler with the help of the velocity concept :)
2) without the dirty tricks (at least up to my understanding) the item can be promoted only basing on his own votes, while I need to compare it to the other item votes