[dev] Datatree_sql::getByAttributes question

[Michael Rubinsky]

Quoting Michael Rubinsky <mike at theupstairsroom.com>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:

>> Quoting Michael Rubinsky <mike at theupstairsroom.com>:
>>
>>> I believe I've tracked the problem down to
>>> Datatree_sql::getByAttributes(). It looks like it performs a
>>> separate  query for each of the [OR] conditions, then puts all the
>>> results into  the $rows array that is returned. The problem is, if
>>> we are setting a  LIMIT, then we could be getting back more than the
>>> $count since *each*  query can return up to $count rows.
>>>
>>> Am I on the right track here?
>>
>> Yup. That was done theoretically for performance. Looks like we either
>> need to do it in one shot if there's a limit, or modify the
>> start/limit parameters (actually just start, right?) based on the # we
>> get back from each consecutive OR.

>> Yea, probably better performance to keep the consecutive queries  
>> and,  like you say, modify the start, and keep track of the  
>> returned row  count so we can break out once LIMIT is reached.

>> Cool. It took me forever to figure that one out! Now I know I'm not  
>>  nuts...well.... ;)

Actually, thinking about this some more, we'll need to modify the  
limit parameter, not the start parameter, based on # of returned rows,  
but more importantly, this won't help with returning duplicate  
rows..unless we iterate / search all the previously returned rows  
before adding a new one.  Now I'm not so sure which would yield better  
performance, do the queries in one shot or separate the queries, but  
check for dups? Hmmm.


Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2013 bytes
Desc: PGP Public Key
Url : http://lists.horde.org/archives/dev/attachments/20070622/6f58a044/attachment.bin