On 5/2/06, Jorge Godoy <[EMAIL PROTECTED]> wrote:
> This might be a problem on really heavy loaded database servers...  But I
> don't see how to do less than "x + 1" queries -- being x the number of pages
> -- if there's some transaction isolation in place solving the above problem
> or really 2 queries per hit if we doesn't solve that (I don't see an easy way
> in an asynchronous connection, specially using a connection pool, but I
> haven't thought much about it).  We'll always need to retrieve the number of
> records that resulted from the search and then we need to show "n" records on
> screen, so there are really 2 queries here.  Retrieving everything is a no-no
> because there might be people with tables containing millions of rows -- a
> log watcher, some statistics on machines running, experiments results, etc.
> -- that would "kill" both the server and the client machine.

I think the way to handle this, if we decide it's necessary at some
point, is to do it the way the search engines do. Hang on to a list of
the first N results (you don't hold all the data, just a reference --
like the ids, or depending on your app, maybe you hold on to the data
that will be in the grid) and page through that. The key here is that
it's probably application dependent, and pagination will likely need
to support (ultimately) different ways of getting at the data.

It also occurs to me that the decorator-based pagination only supports
the notion of a page where you have one bit of pagination going on and
nothing else really happening (unless you use ajax).

It's okay to have limitation in a first take of something, but it's
good to be aware of what those limitations are.

Kevin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---

Reply via email to