I have a solution with my own implementation for Trinidad CollectionModel with
public boolean isRowAvailable() {
if (currentRowIndex > getRowCount()) {
return false;
}
return true;
}
and
public int getRowCount() {
if (size == null) {
size = executeCountQuery();
}
return size.intValue();
}
And it works fast.
Markus Döring
TCC Products GmbH
Von: Renzo Tomaselli [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 17. Januar 2008 12:16
An: MyFaces Discussion
Betreff: Re: [Trinidad] Pagination in a <tr:table>?
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
