[dev] Datatree_sql::getByAttributes question

Michael Rubinsky mike at theupstairsroom.com
Fri Jun 22 21:11:56 UTC 2007


Quoting Michael Rubinsky <mike at theupstairsroom.com>:

> 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.
>

Argh.  Nevermind.  Would need to modify start and limit both...but I  
don't see any way to get rid of dups without having to retrieve all  
rows - starting at the beginning - on each function call, regardless  
of the values start/count since we have no way of knowing what would  
have been returned earlier otherwise....

Guess we need to do it all in one shot, no?

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/dbb23de8/attachment.bin 


More information about the dev mailing list