Hi Igor,
I don't think IDataProvider is only about databases. There are other data
sources and some return the total amount and the desired subset at the same
time (Lucene as a famous example). Such data sources would really benefit of
a single-query-approach. I faced this issue myself in a
On Thu, Nov 27, 2008 at 12:46 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
I don't think IDataProvider is only about databases.
you started off with your core assumption being wrong. idataprovider
was written exclusively for accessing databases. my thinking, at the
time, was that 99% of
Hi Igor,
thanks for implementing this minimal version. i totally agree with your
reasoning. Is there any chance though that this goes into 1.3 branch as
well? I'd really appreciate that.
you mentioned that you implemented such a repeater yourself. didn't you use
any navigation or did you write
On Thu, Nov 27, 2008 at 10:28 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
Hi Igor,
thanks for implementing this minimal version. i totally agree with your
reasoning. Is there any chance though that this goes into 1.3 branch as
well? I'd really appreciate that.
done
you mentioned that
you mentioned that you implemented such a repeater yourself. didn't you
use
any navigation or did you write that yourself? just wondering.
i implemented a simple prev/next pager which is all that was required
or that usecase.
Matej's implementation from inMethods works perfectly. I suggest
I think the idea behind this is that size will be called first. If the
size is zero there is no need to proceed with the call to get the items.
I don't necessarily agree with this approach because a lot of service
calls can capture the data in one call (even down to the database level-
some
We use the same workaround :o)
-Original Message-
From: Michael O'Cleirigh [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 26, 2008 9:43 AM
To: users@wicket.apache.org
Subject: Re: Is there any other way? DataProviders must hit the Db twice
for (possible) large datasets
Hi Wayne,
Hi Wayne,
The way we do it is to only extract the current page from the data
provider once per render cycle.
e.g. the first time size() is called the underlying extraction is
performed to build the list for the size of the current page and all
subsequent calls use this cached value.
You
have a look at https://issues.apache.org/jira/browse/WICKET-1784
Wayne Pope-2 wrote:
Ok,
I was just having a bit of code clean up and I realized that in our
IDataProviders we are loading all rows for a given dataset.
So looking at the iterator method I see we can limit the result (and
Hi,
thanks for the replies.
Micheal O/Hoover - I still don't see how this works as you don't have the
limit and offset (that is used in Iterator). How do you know how many rows
to load in your size() method?
Michael S - thanks for the link - it it appears I must completely rewrite
the whole
We just issue a count(*) query first to get the count. Then, we use
individual queries to get each page's data. If you feel confident enough
that the count won't change (or you don't really care if it does), you can
cache the value returned from it the count query (I don't know how often
that
Hi James,
its not killing anything at the moment, I just don't like the idea of
hitting the database with due cause.
However I thinking about this some more I believe perhaps I should not use
DataViews full stop - but RefreshingView instead?. Essentially I have in
several places a large data set.
Hi Wayne,
if you feel brave enough you can take a look at inmethod grid
components (available in wicket stuff svn -
http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff in trunk
and 1.3 branch). The grid contains AbstractPageableView that can
perform paging without having to know the
Or there's that! :)
On Wed, Nov 26, 2008 at 11:21 AM, Matej Knopp [EMAIL PROTECTED] wrote:
Hi Wayne,
if you feel brave enough you can take a look at inmethod grid
components (available in wicket stuff svn -
http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff in trunk
and 1.3
Hi Matej,
The idea is always to load one row more than required on page which
tells the grid if there will be a next page or not.
Great idea. I looked at the code and I think I'll do my own (simplied
version) of your refreashingpage. I believe thats what we really want here,
as we don't care
You can just take AbstractPageableView, IDataSource and IGridSortState
from the code. It should do exactly what you want and It shouldn't
have any dependencies on the rest of grids.
-Matej
On Wed, Nov 26, 2008 at 5:39 PM, Wayne Pope
[EMAIL PROTECTED] wrote:
Hi Matej,
The idea is always to load
On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
I'm sure I must be missing something still, as I can't beleive that we need
to either a) load the whole data set
what? why would you ever load the whole dataset?
b) call count on the Db , then load in
the iterator mehod.
You've overloaded my sarcasm meter! Darn it, now I have to go buy a new
one.
On Wed, Nov 26, 2008 at 11:58 AM, Igor Vaynberg [EMAIL PROTECTED]wrote:
On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
I'm sure I must be missing something still, as I can't beleive that we
Thanks Matej,
I just noticed org.apache.wicket.markup.repeater.AbstractPageableViewT
which seems what I'm ofter - I'll have a look and both and get something
working.
On Wed, Nov 26, 2008 at 5:57 PM, Matej Knopp [EMAIL PROTECTED] wrote:
You can just take AbstractPageableView, IDataSource and
Hi Igor,
what? why would you ever load the whole dataset?
just to avoid 2 calls on smallish datasets, especially when there are
multiple joins and database isnt on the same box.
yeah. because select count() queries are the most expensive queries
you can run on the database. you are right, its
On Wed, Nov 26, 2008 at 9:06 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
Hi Igor,
what? why would you ever load the whole dataset?
just to avoid 2 calls on smallish datasets, especially when there are
multiple joins and database isnt on the same box.
so you think pushing all that extra data over
so you think pushing all that extra data over the network is actually
more efficient then doing another query wtf.
The point is I'd rather avoid 2 calls where 1 will do. AbstractPageableView
will do fine I believe.
i can only assume that you have actually profiled your app and that
one select
The point is I'd rather avoid 2 calls where 1 will do. AbstractPageableView
will do fine I believe.
You can do the counting and the actual query in one go, with something
like this if you happen to be running on Oracle:
select
data,
count(data) over (order by rownum rows between unbounded
On Wed, Nov 26, 2008 at 9:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
so you think pushing all that extra data over the network is actually
more efficient then doing another query wtf.
The point is I'd rather avoid 2 calls where 1 will do. AbstractPageableView
will do fine I believe.
the
the number of calls itself is meaningless, i dont comprehend why
people have a hard time understanding this simple fact.
The point for me is :
something like
select count(*) from user user1 inner join company com1 on user1.company_id=
com1.id where com1.code='dht2' - called in size()
Wayne,
http://donteattoomuch.blogspot.com/2008/04/partial-ajax-update-capable-list-view.html
This may be interesting too.
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
Wayne Pope-2 wrote:
Thanks Matej,
I just noticed
But the second call is much longer and has a much different point. If you
must display the total rows, you need to do the first call anyway. If you
don't, then use a different component and avoid the first call, only getting
the necessary rows, perhaps plus one to see if there is another page
If you must display the total rows,
which I don't
then use a different component and avoid the first call
Which is what i said in my 3rd post.
On Wed, Nov 26, 2008 at 7:51 PM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
But the second call is much longer and has a much different point. If you
Still is being disputed unfortunately :(
https://issues.apache.org/jira/browse/WICKET-1784
For those who believe in the 1-query approach, ergo the DTO pattern, writing
an alternative to the Wicket data provision using a DTO approach isn't a
terrible hardship ... just annoying to be sprung with
29 matches
Mail list logo
