Re: [Trinidad] Pagination in a ?

[Renzo Tomaselli]

Bart, I noticed this behavior as well, but I was unable to collect any reply from this list. The basic issue is that the page navigator calls isRowAvailable() in the data model many times just to setup a predefined number of ranges in the widget, where the user can select from. These calls in turn endup in probing the database with searches, and here performance drops down. This behavior occurs if you declare in advance the overall dataset size. If this is undefined (-1), then the widget contains one range plus "more ...". I found that the second solution avoids a lot of isRowAvailable() calls. And you cannot be lazy in answering this call: if your model answers yes,  while returnin null at the getRowData(), you end up with a blank row. In any case a significat performance gain is achieve by caching a page, saving/restoring it across requests. Then reload the cache before rendering, if the underlying model might have changed. Hope it helps. -- Renzo [EMAIL PROTECTED] wrote: Hi List, It's fairly easy to implement pagination with a <tr:table> component. Just set the "rows" and "first" attributes and you're done. But it turns out that the pagination is not implemented very smart. Let me explain my case... I have a database with some very large tables (10000 to 100000 records per table). The database is (sadly enough) not too fast. So to make the user interface responsive to the users, it is very important that only the data that is displayed is fetched from the database. Therefore, I implemented a "lazy list", as suggested on http://www.ilikespam.com/blog/lazy_list. I expected to get much better performance, but this did not happen. I added some logging to the lazy list to see what's happening. It turns out that the table is prefetching a lot more rows that the ones that are displayed initially. I did set the "rows" attribute to 10, but it seems the table is fetching about 300 rows at a time. (This takes more than a minute due to my poor performing database...) This can actually be a nice feature, since the user can browse very fast through the next 300 records... once they are loaded. The problem is, however, that the table does not get rendered until the fetching of those 300 records is finished. So my question is: is there a way to configure the fetching strategy of the table component? Is it possible to give rendering a higher priority than prefetching, for instance? Or can I configure how many rows are prefetched? Thanks in advance for your help! Best regards, Bart Kummel