modeling-users

[Modeling-users] Fetching limited numbers of rows

[Kertis, D. <dk...@vo...>]

Is there a way to tell Modeling to only fetch the first N rows?  Ideally,
I'd like to be able to specify an offset and a count to do something like
paging results of a search.

 

Thanks,

Dennis

 

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

[Mario R. <ma...@ru...>]

On Aug 20, 2004, at 9:06 PM, Kertis, Dennis wrote:

> Is there a way to tell Modeling to only fetch the first N rows?=A0=20
> Ideally, I'd like to be able to specify an offset and a count to do=20
> something like paging results of a search.
>
> Thanks,
>
> Dennis

Hi, there were a few discussions on this a while back, including a=20
pretty well-defined proposal to add offset and paging capabilities.=20
Sebastien had also worked on it in a branch, but I do not know what the=20=

status of that is now. Search the mailing list archive for "offset"...=20=

but the main thread about this was:

API cleanup proposal =A0
http://sourceforge.net/mailarchive/message.php?msg_id=3D5142917

limiting the amount of objects retrieved =A0
http://sourceforge.net/mailarchive/message.php?msg_id=3D7163083

limit
http://sourceforge.net/mailarchive/message.php?msg_id=3D4159154

mario=

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

[Sebastien B. <sbi...@us...>]

        Hi Dennis and all,

  To all: if you're using the "Fetch slices and sort orderings" patch,
  I need your feedback, see at end of msg.

Kertis, Dennis wrote:
> Is there a way to tell Modeling to only fetch the first N rows?=A0 Ideall=
y,
> I'd like to be able to specify an offset and a count to do something like
> paging results of a search.

Thanks Mario for the references you posted, I appreciate not having to
search the archives ;)=20

  As Mario already answered, there is a patch doing what you want
  (offset and count in ec.fetch()) You'll find example in the announce,
  hopefully you'll find this useful, and if you need more informations
  then do not hesitate to ask.

Related announce is at:
  http://sourceforge.net/mailarchive/message.php?msg_id=3D7163083
And the patch is at:
  http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D892454&group=
_id=3D58935&atid=3D489337

Mario Ruggier <ma...@ru...> wrote:
> Hi, there were a few discussions on this a while back, including a pretty
> well-defined proposal to add offset and paging capabilities. Sebastien had
> also worked on it in a branch, but I do not know what the status of that =
is
> now.=20

  The status is: wait for comments ;)  It seems that some of you out there
  use this patch, could you please comment? In particular:

     | Current limitations are:
     |=20
     |   - it is available/tested for Postgresql and MySQL only
     |=20
     |   - parameter isDeep shouldn"t be set w/ fetch slices and/or with
     |     sort orderings,
     |=20
     |   - 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

  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!)

-- S=E9bastien.


Mario Ruggier <ma...@ru...> wrote:
> Search the mailing list archive for "offset"... but the main thread about
> this was:
>=20
> API cleanup proposal =A0
> http://sourceforge.net/mailarchive/message.php?msg_id=3D5142917
>=20
> limiting the amount of objects retrieved =A0
> http://sourceforge.net/mailarchive/message.php?msg_id=3D7163083
>=20
> limit
> http://sourceforge.net/mailarchive/message.php?msg_id=3D4159154
>=20
> mario

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