Re: [Modeling-users] Fetching limited numbers of rows

[John L. <jl...@gm...>]

On 24 Aug 2004 23:14:05 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
>=20
>   The status is: wait for comments ;)  It seems that some of you out ther=
e
>   use this patch, could you please comment? In particular:
>=20
>      | Current limitations are:
>      |
>      |   - it is available/tested for Postgresql and MySQL only
>      |
>      |   - parameter isDeep shouldn"t be set w/ fetch slices and/or with
>      |     sort orderings,
>      |
>      |   - inserted (unsaved) objects will appear at the end of each
>      |     result set when limit and/or orderBy is set.  is the
>      |     limitation of having inserted objects
>=20
>   Do you find this annoying?  With which database adaptor(s) do you use
>   it?  I'm asking this because it's out there for a long time, and it's
>   probably time to integrate it into the main trunk (geez, I can't
>   believe the original proposal was more than a year ago!)

I'm using this patch in every single project I'm using Modeling in
(that is one standalone and three integrated in zope). Always with
postgres; if/when one of my customers needs support for this in
something else, I'll find a way for them to sponsor the development :)
(or if cimarr=F3n/luca goes with sqlite, I'll do it on my own steam).

What I'm trying to say is that the first limitation isn't an issue for
me because postgres is my preferred database anyway; the third
limitation isn't really an issue because I have yet to come across a
use case where you insert an object and then request an ordered or
limited list of those same objects without having done a saveChanges
beforehand.

The second limitation comes as a surprise; trying it out, I see that
the problem is that isDeep performs two selects on the database,
instead of one; this is, I guess, so AdaptorChannel doesn't have to
know about it. However, the function needed in DataBaseContext to do
this merging, it seems to me, is SortOrdering's
__compareUsingKeyOrderArray__; the patch is obvious, but that function
has too many underscores for me to call it blithely from another
module. Also, doing it efficiently might be more complicated, because
each call to __compareUsingKeyOrderArray__ might be expensive as it
stands.

--=20
John Lenton (jl...@gm...) -- Random fortune:
bash: fortune: command not found