Re: [Wicket-user] IDataProvider.size()
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
Re: [Wicket-user] IDataProvider.size()
kroekle wrote: 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 I rather think he doesn't want that, as he'd actually like an accurate list of all the page numbers, not just a next link. Lec: If I'm incorrect and you just want a next page link plus links to pages previous to the one you're on, rather than an actual list of all the pages available, please go and comment/vote on the above bug. I think we've done this to death now... Best regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.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
Re: [Wicket-user] IDataProvider.size()
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
Re: [Wicket-user] IDataProvider.size()
you can only do onDetach on the AbstractDetachableReadOnlyModel, but you
can't do it in IDataProvider if you are to cache the result. Even if you
nullify the object in onDetach, the result list still appear in
IDataProvider. How to nullify the result in IDataProvider?
Jeremy Thomerson-2 wrote:
I believe that the onDetach() { result = null; } should take care of that.
At the end of the request, that will be called and your cache will be
blown away, which means you are as safe as any other way (memory wise),
because the data is only held for the length of the request.
You can verify, but I don't think memory will be an issue there.
--
Jeremy Thomerson
jthomerson AT users DOT sourceforge DOT net
On 6/10/07, Lec [EMAIL PROTECTED] wrote:
Why would want to cache the result? what happened if the results returned
are
big and if that s not enought, what will happened if 5000 concurrent
users
are accessing the paging and hence caching a potential big records
returned?
the memory of the server will be eaten away right?
Timo Stamm wrote:
Steve Knight schrieb:
If my SortableDataProvider implementation will always return the max
number
of results (I'm not using paging), is it safe to have the size()
method
simply return Integer.MAX_VALUE instead of performing a database query
to
count the actual results?
You shouldn't. It might not give you problems right now, but you break
the contract with the interface.
You can cache the result so that you do only one query per request to
get both the result size and the result values. Use onDetach to clear
the cache after each request.
It should look like this (pseudo-code):
private List result;
void onDetach() {
result = null;
}
Iterator iterator(from, to) {
return getData().iterator();
}
int size() {
return result.size();
}
private Collection getData() {
if (result == null) {
result = dbquery(from, to);
}
return result;
}
Timo
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/IDataProvider.size%28%29-tf1317737.html#a11055063
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
-
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
--
View this message in context:
http://www.nabble.com/IDataProvider.size%28%29-tf1317737.html#a11055597
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
Re: [Wicket-user] IDataProvider.size()
you can only do onDetach on the AbstractDetachableReadOnlyModel, but you can't do it in IDataProvider if you are to cache the result. In Wicket 1.3 you can. 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
Re: [Wicket-user] IDataProvider.size()
i believe even in 1.2.6 you can mix in idetachable. in 1.3 idataprovider extends it directly. -igor On 6/10/07, Eelco Hillenius [EMAIL PROTECTED] wrote: you can only do onDetach on the AbstractDetachableReadOnlyModel, but you can't do it in IDataProvider if you are to cache the result. In Wicket 1.3 you can. 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
Re: [Wicket-user] IDataProvider.size()
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
--
View this message in context:
http://www.nabble.com/IDataProvider.size%28%29-tf1317737.html#a11055761
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
Re: [Wicket-user] IDataProvider.size()
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
Re: [Wicket-user] IDataProvider.size()
On 6/11/07, Johan Karlberg [EMAIL PROTECTED] 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. Yep. 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
Re: [Wicket-user] IDataProvider.size()
Lec wrote: so what s the most optimized way of doing paging using the IDataProvider? There is no optimal way. You have to engage your brain and make trade-offs, just like you do with everything else. You can make sure your database is configured to cache the COUNT(*) query, which will be as efficient as you need, I imagine. It will probably also stop you getting stale values, depending how your database vendor handles things. However, even if it caches it, you need to roundtrip to your database to find it, which you may consider sub-optimal. To avoid this, you can cache the result of COUNT(*) in your DAO layer for some time (a few seconds or a minute, say). You then need to decide how to cope with stale values. You can cache the result of COUNT(*) in your DAO layer and make that layer intelligently expunge the cache when you run DELETE or INSERT statements, but that assumes nothing external to your DAO layer will be touching the database and that you're not clustering your application. You can make the above cluster-safe by mixing in JGroups or JMS or something else that can send clustered cache invalidations around the place, but you still have external modification issues. You can combine the above with cache timeouts to give you a blend of both, and tune the rate of invalidation messages (you could group multiple entity invalidations into a single message) and also tune the timeout values to give an acceptable trade-off between data staleness and speed. This trade-off will be different depending on lots of factors, including what sort of data you're displaying, how big a performance bottleneck this really is (ideally you want realtime updates, so have you profiled it to make sure you really need to cache things and serve potentially stale data yet?). See, there is no optimal way. If the above confuses you, just do what 99% of people will do, and rely on your MySQL or whatever to cache the value for you and don't worry about it. If you're really concerned, you can profile your application and fix the bottlenecks. They probably won't be where you think they will. Premature optimisation is the root of all evil. Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.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
Re: [Wicket-user] IDataProvider.size()
Why would want to cache the result? what happened if the results returned are
big and if that s not enought, what will happened if 5000 concurrent users
are accessing the paging and hence caching a potential big records returned?
the memory of the server will be eaten away right?
Timo Stamm wrote:
Steve Knight schrieb:
If my SortableDataProvider implementation will always return the max
number
of results (I'm not using paging), is it safe to have the size() method
simply return Integer.MAX_VALUE instead of performing a database query to
count the actual results?
You shouldn't. It might not give you problems right now, but you break
the contract with the interface.
You can cache the result so that you do only one query per request to
get both the result size and the result values. Use onDetach to clear
the cache after each request.
It should look like this (pseudo-code):
private List result;
void onDetach() {
result = null;
}
Iterator iterator(from, to) {
return getData().iterator();
}
int size() {
return result.size();
}
private Collection getData() {
if (result == null) {
result = dbquery(from, to);
}
return result;
}
Timo
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/IDataProvider.size%28%29-tf1317737.html#a11055063
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
Re: [Wicket-user] IDataProvider.size()
I believe that the onDetach() { result = null; } should take care of that.
At the end of the request, that will be called and your cache will be
blown away, which means you are as safe as any other way (memory wise),
because the data is only held for the length of the request.
You can verify, but I don't think memory will be an issue there.
--
Jeremy Thomerson
jthomerson AT users DOT sourceforge DOT net
On 6/10/07, Lec [EMAIL PROTECTED] wrote:
Why would want to cache the result? what happened if the results returned
are
big and if that s not enought, what will happened if 5000 concurrent users
are accessing the paging and hence caching a potential big records
returned?
the memory of the server will be eaten away right?
Timo Stamm wrote:
Steve Knight schrieb:
If my SortableDataProvider implementation will always return the max
number
of results (I'm not using paging), is it safe to have the size() method
simply return Integer.MAX_VALUE instead of performing a database query
to
count the actual results?
You shouldn't. It might not give you problems right now, but you break
the contract with the interface.
You can cache the result so that you do only one query per request to
get both the result size and the result values. Use onDetach to clear
the cache after each request.
It should look like this (pseudo-code):
private List result;
void onDetach() {
result = null;
}
Iterator iterator(from, to) {
return getData().iterator();
}
int size() {
return result.size();
}
private Collection getData() {
if (result == null) {
result = dbquery(from, to);
}
return result;
}
Timo
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/IDataProvider.size%28%29-tf1317737.html#a11055063
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
-
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
Re: [Wicket-user] IDataProvider.size()
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 IIRC, that will display Integer.MAX_VALUE on the page which is probably not what you want. You might look into caching that value. Steve Knight wrote: If my SortableDataProvider implementation will always return the max number of results (I'm not using paging), is it safe to have the size() method simply return Integer.MAX_VALUE instead of performing a database query to count the actual results? Steve - -- Justin Lee http://www.antwerkz.com AIM : evan chooly 720.299.0101 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFEIBGyJnQfEGuJ90MRA3YXAJ9LrXkc74ZWRXyZvMxYuN9FBafl7ACeNNxz zHnAebjt0Eu3bnn9JPIJAZs= =Jilb -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] IDataProvider.size()
size is used for calculating the number of pages available. if you dont page you should probably be fine. -Igor On 3/21/06, Steve Knight [EMAIL PROTECTED] wrote: Well, I tried it and it seems to work fine. I get the expected results. I'm just not sure if there is a performance or other reason not to do it as I am not sure how the value is used by DataView.The database query doesn't always retrieve the same results as there is a filter applied to it, so I don't think caching will work. SteveOn 3/21/06, Justin Lee [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE-Hash: RIPEMD160IIRC, that will display Integer.MAX_VALUE on the page which is probablynot what you want.You might look into caching that value.Steve Knight wrote: If my SortableDataProvider implementation will always return the max number of results (I'm not using paging), is it safe to have the size() method simply return Integer.MAX_VALUE instead of performing a database query to count the actual results? Steve- --Justin Leehttp://www.antwerkz.com AIM : evan chooly720.299.0101-BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin)iD8DBQFEIBGyJnQfEGuJ90MRA3YXAJ9LrXkc74ZWRXyZvMxYuN9FBafl7ACeNNxzzHnAebjt0Eu3bnn9JPIJAZs==Jilb-END PGP SIGNATURE This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] IDataProvider.size()
Steve Knight schrieb:
If my SortableDataProvider implementation will always return the max number
of results (I'm not using paging), is it safe to have the size() method
simply return Integer.MAX_VALUE instead of performing a database query to
count the actual results?
You shouldn't. It might not give you problems right now, but you break
the contract with the interface.
You can cache the result so that you do only one query per request to
get both the result size and the result values. Use onDetach to clear
the cache after each request.
It should look like this (pseudo-code):
private List result;
void onDetach() {
result = null;
}
Iterator iterator(from, to) {
return getData().iterator();
}
int size() {
return result.size();
}
private Collection getData() {
if (result == null) {
result = dbquery(from, to);
}
return result;
}
Timo
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
