Batches in ZPT: not stateful, yet...
Greetings, I have a question about batches in ZPT (and in <dtml-in>, for that matter.) Given the stateless nature of HTTP, how is the batch itself persisted across calls to display a portion of the batch? For example, if I get a database search returning several hundred (or thousand) rows, of which I display 50 at a time, I (or Batch) presumably needs to cache those values somewhere: or is it assumed that the sequence will be regenerated within the bounds set? TIA, tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever"
The state (batch_size, next_batch_start, etc.) is typically kept in the query string. - C On Tue, 2003-01-21 at 17:35, Tom Emerson wrote:
Greetings,
I have a question about batches in ZPT (and in <dtml-in>, for that matter.) Given the stateless nature of HTTP, how is the batch itself persisted across calls to display a portion of the batch? For example, if I get a database search returning several hundred (or thousand) rows, of which I display 50 at a time, I (or Batch) presumably needs to cache those values somewhere: or is it assumed that the sequence will be regenerated within the bounds set?
TIA,
tree -- Chris McDonough <chrism@zope.com> Zope Corporation
Chris McDonough writes:
The state (batch_size, next_batch_start, etc.) is typically kept in the query string.
Right, I got that. But the batch itself: if I have a SQL method that is returning a result set, is that called for each subset of records in the batch?
- C
On Tue, 2003-01-21 at 17:35, Tom Emerson wrote:
Greetings,
I have a question about batches in ZPT (and in <dtml-in>, for that matter.) Given the stateless nature of HTTP, how is the batch itself persisted across calls to display a portion of the batch? For example, if I get a database search returning several hundred (or thousand) rows, of which I display 50 at a time, I (or Batch) presumably needs to cache those values somewhere: or is it assumed that the sequence will be regenerated within the bounds set?
TIA,
tree -- Chris McDonough <chrism@zope.com> Zope Corporation
-- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever"
On Tue, 2003-01-21 at 17:50, Tom Emerson wrote:
Right, I got that. But the batch itself: if I have a SQL method that is returning a result set, is that called for each subset of records in the batch?
Yes, it is (modulo any caching you're doing on the SQL method). - C
Chris McDonough writes:
On Tue, 2003-01-21 at 17:50, Tom Emerson wrote:
Right, I got that. But the batch itself: if I have a SQL method that is returning a result set, is that called for each subset of records in the batch?
Yes, it is (modulo any caching you're doing on the SQL method).
OK, that is what I feared. I take it the magic insertion of a LIMIT on the SQL query happens automagically? Or does the whole thing get returned and bits dropped? Within ZPT it looks like it would be possible to subclass ZTUtils.Batch to be more intelligent about fetching information... Anyway, thanks Chris for your help. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever"
On Tue, 2003-01-21 at 18:03, Tom Emerson wrote:
OK, that is what I feared. I take it the magic insertion of a LIMIT on the SQL query happens automagically? Or does the whole thing get returned and bits dropped?
Yes, the row limit happens automatically but can be adjusted. Only as many rows as necessary up to the limit are conjured up from the underlying database, no bits are dropped. See http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/RelationalDataba... for more information.
Within ZPT it looks like it would be possible to subclass ZTUtils.Batch to be more intelligent about fetching information...
ZTUtils looks like it's as lazy as possible, but when you construct a new one on every request, obviously the old one's state goes away and you incur the expense all over again. If you aren't worried too much about dataset invalidation (if your data is pretty static) or getting potentially different results between threads, you could probably stick a Batch object as an "_v_batch" attribute of a convenient persistent object in your code. Objects stored as "_v_" attributes of a persistent object are implicitly tied to a thread and though their lifetime is unpredictable and not guaranteed, they typically last longer than a single request (and sometimes much longer), so they are perfect for caching. See the Zope Developer's guide for more info.
Anyway, thanks Chris for your help.
Sure!
-- Chris McDonough <chrism@zope.com> Zope Corporation
On Wednesday, January 22, 2003, at 09:50 AM, Tom Emerson wrote:
Chris McDonough writes:
The state (batch_size, next_batch_start, etc.) is typically kept in the query string.
Right, I got that. But the batch itself: if I have a SQL method that is returning a result set, is that called for each subset of records in the batch?
Yes. Unless you choose to stuff the results into SESSION and use that to iterate over. Doing this requires making the results picklable: <tal:block condition="request/SESSION/results|nothing"> <tal:block condition="request/SESSION.set('results',[tuple(row) for row in path('here/zsqlmethod')]" /> </tal:block> <table> <tr tal:repeat="row request/SESSION/results"> <td tal:repeat="cell row" tal:content="cell">cell</td> </tr> </table> Or something like that... -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
participants (3)
-
Chris McDonough -
Stuart Bishop -
Tom Emerson