[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