Closed (won't fix)
Project:
Voting API
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
27 Mar 2013 at 19:55 UTC
Updated:
16 Apr 2013 at 06:36 UTC
Jump to comment: Most recent file
Comments
Comment #1
andypostplease do not change mymodule here
no reason to prefix $query each line - use chaning
Comment #2
spleshkaThanks @andy, new patch attached.
Comment #3
spleshkaFixed lines indents.
Comment #4
eaton commentedAt least as of the code that I wrote, the use of db_query for SELECTs was quite deliberate! the PDO DBTNG query builder is much slower for simple selects, and unless the query is extremely dynamic (as with the generic aggregation query that DOES use PDO), there isn't much to be gained in code style, either.
Larry Garfield, one of the DBTNG architects, weighs in on the issue with VotingAPI used as a specific example in this blog post.
I'm not opposed to the conversion on philosophical grounds, but given the potential performance implications of one of the more speed-sensitive parts of VotingAPI, it'd be a shame to do it without thinking through the implications.
Comment #5
andypostNow it looks nicer
EDIT I think this queries a much more expensive so impact of their conversion to db_select() is less evil. But readablity and alterability could be useful
Comment #6
spleshkaWhat about extending this queries by adding some tags to them? It will make this queries more flexible for other developers. I mean if we provide a new feature that uses power of PDO, will it be a good reason for convertsion of old queries?
Comment #7
spleshkaAgree with @andypost: conversion could lead to loss of 1ms for two main queries, but that queries are much more expensive than 1ms.
Comment #8
spleshkaBy the way, speaking about expensive recalculate operations. We could use here same trick as User Points module does: when new points should be added, they do not recalculate all single points. Instead of that they simply add or remove certain amount of points from table with cached results. Could we implement similar functionality into VotingAPI? it will bring a great performance boost. I understand that this is a separate issue, but I should know if you like this idea.
Comment #9
spleshkaOh, I missed that I've changed issue status. Return the previous value.
Comment #10
torotil commentedI don't think that performance is an issue here. But it still boils down to the questions:
@Spleshka: I'm currently pondering an object oriented API for results that could also support incremental calculations. This would also have the advantage that you don't need to store the individual votes except to limit the number of times someone can vote. But this is a completely different issue.
I'm leaving this open for the while. But unless someone provides an otherwise not possible use-case this is a wontfix for me.
Comment #11
torotil commentedComment #11.0
torotil commentedFixed my English.