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)
This has been implemented and is about 5 minutes away from being rejected: https://issues.apache.org/jira/browse/WICKET-579 Johan Karlberg wrote: > > 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 > > If what you want is a pager that doesn't care about the count, implement -- View this message in context: http://www.nabble.com/IDataProvider.size%28%29-tf1317737.html#a11079393 Sent from the Wicket - User mailing list archive at Nabble.com. ------------------------------------------------------------------------- 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
