If it's only the repeated execution of a count projection that bothers
you, what Eelco suggest is likely not caching the data returned by the
iterator, it's caching the long returned by size(). It will decrease the
accuracy of the pager in favor of performance, and will not contribute
to significant increase in memory use.
The interface to IDataProvider does require you to provide a size, but
it puts no limitation on how you retrieve that size. If you can
construct a query to return the size alongside your resultset, or your
datalayer otherwise can provide the count baed on the data query alone,
by all means, use it.
If what you want is a pager that doesn't care about the count, implement
it, either as a separate dataTable-esque component, or by modifying the
existing one (which I suspect might even get included, if it leave the
existing implementaiton compatible with existing users of it)
Johan
Lec wrote:
> Eelco,
> What i mean is that, you don't necessary have to cache the result
> just do the paging lists. you can directly call the db to query the page
> just like that...
>
> void iterator( int first, int count)
> {
> db.getPage( parameter, first, count ).iterator();
> }
>
> int size()
> {
> db.getPageCount( parameter );
> }
>
> This approach make heavy db call. Imagine there are 5000 concurrent users
> making the same paging, with no constant data changing at the backend (
> adding or deletion of data ), then the db will be heavy-loaded with
> unnecessary duplication db call - size(). And I realise this is not an
> efficient way of pagination, is it?
>
> To avoid this problem, you suggested to cache the results or even the result
> size, so that subsequently paging call will not trigger the same
> db.getPageCount( parameter ) or even the db.getPage( parameter, first, count
> ).iterator(); Having said that, however, if you look at it, you will
> realise caching is also not an efficient way of doing a paging list,
> considering all the records returned might be a potential big record. And if
> these records are stored in a List, the memory of the server will be eaten
> away especially when the paging site is heavy loaded with concurrent users,
> say 5000 concurrent users are doing the same paging. get me? :)
>
> so what s the most optimized way of doing paging using the IDataProvider?
>
>
>
>
>
> Eelco Hillenius wrote:
>>> Why would want to cache the result?
>> Look, you have to make a decission. Are you interested in paging lists
>> or not? If you are, you should do a count query to determine how many
>> rows there are, and then just load the page of results you need with
>> another one. If you don't want to use paging, but you want to display
>> the whole result set at once, Timo's answer will work fine.
>>
>>> what happened if the results returned are big
>> If the results can be big, use a pageable list. It's the whole point
>> of the constructs we have that these components will load just what is
>> needed instead of all the results.
>>
>> Eelco
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Wicket-user mailing list
>> Wicket-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
>>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
