subject:"Re\: Is there any other way\? DataProviders must hit the Db twice for \(possible\) large datasets"

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Stefan Fußenegger

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 search (read Lucene)
centered application. I successfully went down the road of implementing a
custom repeater. But when the repeater was working as desired, I figured out
that PagingNavigationLink is the real showstopper, not IDataProvider (see my
JIRA comment [0]). The fix would be rather trivial, as PagingNavigationLink
is doing something it needn't do (checking the requested page against the
valid range of pages).

Let me answer 2 possible questions in advance:

Q: Why is this check in PagingNavigationLink a problem?
A: Obviously, you can't fetch size and data as long as the page isn't known.

Q: How would a custom repeater that fetches data and size at the same tame
handle invalid (out of range) pages?
A: Out of range pages will return the size and an empty dataset. In this
case, the repeater would change the page number to the last valid and do a
second query. Yeah, two queries again. But this should only happen rarely
though.

Best regards, Stefan

[0]
https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278

igor.vaynberg wrote:

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 number of calls itself is meaningless, i dont comprehend why
people have a hard time understanding this simple fact.

if you have one call that takes 1000ms and ten calls that each take
10ms you should concentrate on the one call that takes a long time
rather then eliminating all ten 10ms calls which only saves you 100ms.
if you can optimize the 1000ms and shave off 20% then your eleven
calls are still faster then the one call.

and since connection pools have been inventind many years ago there is
no more overhead of establishing network connections, just pushing
bits around. maybe that is still a problem in php, but in java it has
been solved a long time ago.

-igor

i can only assume that you have actually profiled your app and that
one select count() call was what was taking a significant chunk of
processing time in the database server? to the point where eliminating
it will actually reduce enough load on the database to increase your
throughput?

No I haven't, as mentioned before, I just want to avoid 2 calls when one
will do. I have however seen several times in production systems waiting
on
i/o's reduces your scalability. I'd rather keep server count down as
money
is tight.
I'll be mindfull not to ask 'stupid' questions again.

On Wed, Nov 26, 2008 at 6:19 PM, Igor Vaynberg
[EMAIL PROTECTED]wrote:

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 the network is actually
more efficient then doing another query wtf.

yeah. because select count() queries are the most expensive queries
you can run on the database. you are right, its totally going to kill
it. you know how all those sites on the internet that have a pager
above the pageable view that shows you the number of the last
available page...you know how those work without doing a select
count()?

Ouch.
I just want to limit calls if possible to the database as waiting for
i/o's
is never great for scalability. I'm not 'having a go' at wicket or
DataViews
or anything, just trying to understand it. I never claimed to be a
guru -
far from it.

-igor

Wayne

On Wed, Nov 26, 2008 at 5:58 PM, 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
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. Thats going to kill the database in prod (or
really
not
help.)

yeah. because select count() queries are the most expensive queries
you can run on the database. you are right, its totally going to kill
it. you know how all those sites on the

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Igor Vaynberg

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 people use wicket to build applications that
access databases, and i dare say it was a good guess because in its ~3
years of existence only a handful of people had a problem with the way
it works.

 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 am not disputing this fact. i am simply saying that we are not going
to fix this right now because this is not a bug. you are trying to use
the components for something they were not designed to be used. in 1.5
we may address this.

 I faced this issue myself in a search (read Lucene)
 centered application. I successfully went down the road of implementing a
 custom repeater.

i had to do the same myself.

 But when the repeater was working as desired, I figured out
 that PagingNavigationLink is the real showstopper, not IDataProvider (see my
 JIRA comment [0]). The fix would be rather trivial, as PagingNavigationLink
 is doing something it needn't do (checking the requested page against the
 valid range of pages).

 Let me answer 2 possible questions in advance:

 Q: Why is this check in PagingNavigationLink a problem?
 A: Obviously, you can't fetch size and data as long as the page isn't known.

the check is there because we code defensively. we do not assume that
every implementation of ipageable will cull the number when you call
setcurrentpage(x).

 Q: How would a custom repeater that fetches data and size at the same tame
 handle invalid (out of range) pages?
 A: Out of range pages will return the size and an empty dataset. In this
 case, the repeater would change the page number to the last valid and do a
 second query. Yeah, two queries again. But this should only happen rarely
 though.

this will change the existing behavior. if you are on page 5 and click
page 10 (which happens to not exist) you would end up back on 5 with
your suggestion where as currently you would properly end up on 9.

looking at WICKET-1784, i extracted the code you want into an
overridable int cullPageNumber(int x). so feel free to subclass the
link and override that to return x without any extra checks.

we may properly fix this in 1.5, but for right now this is too big a
refactor because it changes the basic assumptions with which the code
was written.

-igor


 Best regards, Stefan

 [0]
 https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278


 igor.vaynberg wrote:

 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 number of calls itself is meaningless, i dont comprehend why
 people have a hard time understanding this simple fact.

 if you have one call that takes 1000ms and ten calls that each take
 10ms you should concentrate on the one call that takes a long time
 rather then eliminating all ten 10ms calls which only saves you 100ms.
 if you can optimize the 1000ms and shave off 20% then your eleven
 calls are still faster then the one call.

 and since connection pools have been inventind many years ago there is
 no more overhead of establishing network connections, just pushing
 bits around. maybe that is still a problem in php, but in java it has
 been solved a long time ago.

 -igor



i can only assume that you have actually profiled your app and that
one select count() call was what was taking a significant chunk of
processing time in the database server? to the point where eliminating
it will actually reduce enough load on the database to increase your
throughput?

 No I haven't, as mentioned before, I just want to avoid 2 calls when one
 will do.  I have however seen several times in production systems waiting
 on
 i/o's reduces your scalability. I'd rather keep server count down as
 money
 is tight.
 I'll be mindfull not to ask 'stupid' questions again.



 On Wed, Nov 26, 2008 at 6:19 PM, Igor Vaynberg
 [EMAIL PROTECTED]wrote:

 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 the network is actually
 more efficient then doing another query wtf.

 yeah. because select count() queries are the most expensive queries
 you can run on the database. you are right, its totally going to kill

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Stefan Fußenegger


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 that yourself? just wondering.

shall i open a ticket against 1.5 to track this issue/enhancement?

best regards, stefan



igor.vaynberg wrote:
 
 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 people use wicket to build applications that
 access databases, and i dare say it was a good guess because in its ~3
 years of existence only a handful of people had a problem with the way
 it works.
 
 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 am not disputing this fact. i am simply saying that we are not going
 to fix this right now because this is not a bug. you are trying to use
 the components for something they were not designed to be used. in 1.5
 we may address this.
 
 I faced this issue myself in a search (read Lucene)
 centered application. I successfully went down the road of implementing a
 custom repeater.
 
 i had to do the same myself.
 
 But when the repeater was working as desired, I figured out
 that PagingNavigationLink is the real showstopper, not IDataProvider (see
 my
 JIRA comment [0]). The fix would be rather trivial, as
 PagingNavigationLink
 is doing something it needn't do (checking the requested page against the
 valid range of pages).

 Let me answer 2 possible questions in advance:

 Q: Why is this check in PagingNavigationLink a problem?
 A: Obviously, you can't fetch size and data as long as the page isn't
 known.
 
 the check is there because we code defensively. we do not assume that
 every implementation of ipageable will cull the number when you call
 setcurrentpage(x).
 
 Q: How would a custom repeater that fetches data and size at the same
 tame
 handle invalid (out of range) pages?
 A: Out of range pages will return the size and an empty dataset. In this
 case, the repeater would change the page number to the last valid and do
 a
 second query. Yeah, two queries again. But this should only happen rarely
 though.
 
 this will change the existing behavior. if you are on page 5 and click
 page 10 (which happens to not exist) you would end up back on 5 with
 your suggestion where as currently you would properly end up on 9.
 
 looking at WICKET-1784, i extracted the code you want into an
 overridable int cullPageNumber(int x). so feel free to subclass the
 link and override that to return x without any extra checks.
 
 we may properly fix this in 1.5, but for right now this is too big a
 refactor because it changes the basic assumptions with which the code
 was written.
 
 -igor
 

 Best regards, Stefan

 [0]
 https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278


 igor.vaynberg wrote:

 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 number of calls itself is meaningless, i dont comprehend why
 people have a hard time understanding this simple fact.

 if you have one call that takes 1000ms and ten calls that each take
 10ms you should concentrate on the one call that takes a long time
 rather then eliminating all ten 10ms calls which only saves you 100ms.
 if you can optimize the 1000ms and shave off 20% then your eleven
 calls are still faster then the one call.

 and since connection pools have been inventind many years ago there is
 no more overhead of establishing network connections, just pushing
 bits around. maybe that is still a problem in php, but in java it has
 been solved a long time ago.

 -igor



i can only assume that you have actually profiled your app and that
one select count() call was what was taking a significant chunk of
processing time in the database server? to the point where eliminating
it will actually reduce enough load on the database to increase your
throughput?

 No I haven't, as mentioned before, I just want to avoid 2 calls when
 one
 will do.  I have however seen several times in production systems
 waiting
 on
 i/o's reduces your scalability. I'd rather keep server count down as
 money
 is tight.
 I'll be mindfull not to ask 'stupid' questions again.



 On Wed, Nov 26, 2008 at 6:19 PM, Igor Vaynberg
 [EMAIL PROTECTED]wrote:

 On Wed, Nov 26, 2008 at 9:06

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Igor Vaynberg

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 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
for that usecase.

 shall i open a ticket against 1.5 to track this issue/enhancement?

i added it to the wishlist wiki page. if you add a jira ticket please
add the number to the wiki page.

-igor


 best regards, stefan



 igor.vaynberg wrote:

 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 people use wicket to build applications that
 access databases, and i dare say it was a good guess because in its ~3
 years of existence only a handful of people had a problem with the way
 it works.

 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 am not disputing this fact. i am simply saying that we are not going
 to fix this right now because this is not a bug. you are trying to use
 the components for something they were not designed to be used. in 1.5
 we may address this.

 I faced this issue myself in a search (read Lucene)
 centered application. I successfully went down the road of implementing a
 custom repeater.

 i had to do the same myself.

 But when the repeater was working as desired, I figured out
 that PagingNavigationLink is the real showstopper, not IDataProvider (see
 my
 JIRA comment [0]). The fix would be rather trivial, as
 PagingNavigationLink
 is doing something it needn't do (checking the requested page against the
 valid range of pages).

 Let me answer 2 possible questions in advance:

 Q: Why is this check in PagingNavigationLink a problem?
 A: Obviously, you can't fetch size and data as long as the page isn't
 known.

 the check is there because we code defensively. we do not assume that
 every implementation of ipageable will cull the number when you call
 setcurrentpage(x).

 Q: How would a custom repeater that fetches data and size at the same
 tame
 handle invalid (out of range) pages?
 A: Out of range pages will return the size and an empty dataset. In this
 case, the repeater would change the page number to the last valid and do
 a
 second query. Yeah, two queries again. But this should only happen rarely
 though.

 this will change the existing behavior. if you are on page 5 and click
 page 10 (which happens to not exist) you would end up back on 5 with
 your suggestion where as currently you would properly end up on 9.

 looking at WICKET-1784, i extracted the code you want into an
 overridable int cullPageNumber(int x). so feel free to subclass the
 link and override that to return x without any extra checks.

 we may properly fix this in 1.5, but for right now this is too big a
 refactor because it changes the basic assumptions with which the code
 was written.

 -igor


 Best regards, Stefan

 [0]
 https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278


 igor.vaynberg wrote:

 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 number of calls itself is meaningless, i dont comprehend why
 people have a hard time understanding this simple fact.

 if you have one call that takes 1000ms and ten calls that each take
 10ms you should concentrate on the one call that takes a long time
 rather then eliminating all ten 10ms calls which only saves you 100ms.
 if you can optimize the 1000ms and shave off 20% then your eleven
 calls are still faster then the one call.

 and since connection pools have been inventind many years ago there is
 no more overhead of establishing network connections, just pushing
 bits around. maybe that is still a problem in php, but in java it has
 been solved a long time ago.

 -igor



i can only assume that you have actually profiled your app and that
one select count() call was what was taking a significant chunk of
processing time in the database server? to the point where eliminating
it will actually reduce enough load on the database to increase your
throughput?

 No I haven't, as mentioned before, I just want to avoid 2 calls when
 one
 will do.  I have however seen several times in

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-27 Thread Wayne Pope

 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 you use
that Stefan if you need such a thing.
(Thanks Matej!)




On Thu, Nov 27, 2008 at 7:51 PM, Igor Vaynberg [EMAIL PROTECTED]wrote:

 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 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
 for that usecase.

  shall i open a ticket against 1.5 to track this issue/enhancement?

 i added it to the wishlist wiki page. if you add a jira ticket please
 add the number to the wiki page.

 -igor

 
  best regards, stefan
 
 
 
  igor.vaynberg wrote:
 
  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 people use wicket to build applications that
  access databases, and i dare say it was a good guess because in its ~3
  years of existence only a handful of people had a problem with the way
  it works.
 
  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 am not disputing this fact. i am simply saying that we are not going
  to fix this right now because this is not a bug. you are trying to use
  the components for something they were not designed to be used. in 1.5
  we may address this.
 
  I faced this issue myself in a search (read Lucene)
  centered application. I successfully went down the road of implementing
 a
  custom repeater.
 
  i had to do the same myself.
 
  But when the repeater was working as desired, I figured out
  that PagingNavigationLink is the real showstopper, not IDataProvider
 (see
  my
  JIRA comment [0]). The fix would be rather trivial, as
  PagingNavigationLink
  is doing something it needn't do (checking the requested page against
 the
  valid range of pages).
 
  Let me answer 2 possible questions in advance:
 
  Q: Why is this check in PagingNavigationLink a problem?
  A: Obviously, you can't fetch size and data as long as the page isn't
  known.
 
  the check is there because we code defensively. we do not assume that
  every implementation of ipageable will cull the number when you call
  setcurrentpage(x).
 
  Q: How would a custom repeater that fetches data and size at the same
  tame
  handle invalid (out of range) pages?
  A: Out of range pages will return the size and an empty dataset. In
 this
  case, the repeater would change the page number to the last valid and
 do
  a
  second query. Yeah, two queries again. But this should only happen
 rarely
  though.
 
  this will change the existing behavior. if you are on page 5 and click
  page 10 (which happens to not exist) you would end up back on 5 with
  your suggestion where as currently you would properly end up on 9.
 
  looking at WICKET-1784, i extracted the code you want into an
  overridable int cullPageNumber(int x). so feel free to subclass the
  link and override that to return x without any extra checks.
 
  we may properly fix this in 1.5, but for right now this is too big a
  refactor because it changes the basic assumptions with which the code
  was written.
 
  -igor
 
 
  Best regards, Stefan
 
  [0]
 
 https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278
 
 
  igor.vaynberg wrote:
 
  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 number of calls itself is meaningless, i dont comprehend why
  people have a hard time understanding this simple fact.
 
  if you have one call that takes 1000ms and ten calls that each take
  10ms you should concentrate on the one call that takes a long time
  rather then eliminating all ten 10ms calls which only saves you 100ms.
  if you can optimize the 1000ms and shave off 20% then your eleven
  calls are still faster then the one call.
 
  and since connection pools have been inventind many years ago there is
  no more overhead of

RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Hoover, William

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 support getting the size/results in one call), but the last time I
brought this issue up it was disputed.

-Original Message-
From: Wayne Pope [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 26, 2008 9:20 AM
To: users@wicket.apache.org
Subject: Is there any other way? DataProviders must hit the Db twice for
(possible) large datasets

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 the
offset). Great I thought - however I see that that the size() method is
called as part of the getViewSize() in the AbstractPageableView. Thus I
need to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice for
each DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Hoover, William

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,

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 just need to clear the cached state in provider.detach() so that the
next time size() is called (on the next render) the data will be
reloaded properly.

With our project we use the size of the data provider to determine
component visibility (i.e. 0 rows == is visible) which results in alot
more calls of provider.size() but with this caching approach the
rendering performance is not impacted.

Regards,

Mike

 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 
 the offset). Great I thought - however I see that that the size() 
 method is called as part of the getViewSize() in the 
 AbstractPageableView. Thus I need to call the database here to figure
out the size.

 Am I doing sonething wrong or have I got to hit the database twice for

 each DataProvider render.

 Obvously I don't want to hard code a size. Is there any other way ?

 Thanks
 Wayne

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Michael O'Cleirigh


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 just need to clear the cached state in provider.detach() so that the 
next time size() is called (on the next render) the data will be 
reloaded properly.


With our project we use the size of the data provider to determine 
component visibility (i.e. 0 rows == is visible) which results in alot 
more calls of provider.size() but with this caching approach the 
rendering performance is not impacted.


Regards,

Mike


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 the
offset). Great I thought - however I see that that the size() method is
called as part of the getViewSize() in the AbstractPageableView. Thus I need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice for each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Michael Sparer


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 the
 offset). Great I thought - however I see that that the size() method is
 called as part of the getViewSize() in the AbstractPageableView. Thus I
 need
 to call the database here to figure out the size.
 
 Am I doing sonething wrong or have I got to hit the database twice for
 each
 DataProvider render.
 
 Obvously I don't want to hard code a size. Is there any other way ?
 
 Thanks
 Wayne
 
 


-
Michael Sparer
http://talk-on-tech.blogspot.com
-- 
View this message in context: 
http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20702476.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

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 pagable/provider code (not looked at the code) to get this to
work?

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 b) call count on the Db , then load in
the iterator mehod. Thats going to kill the database in prod (or really not
help.)

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]wrote:

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 the
offset). Great I thought - however I see that that the size() method is
called as part of the getViewSize() in the AbstractPageableView. Thus I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:
http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20702476.html
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread James Carman

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 gets called, really). If calling the queries to get the individual
page's data is killing your database, then you're doing something wrong,
IMHO.

On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:

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 pagable/provider code (not looked at the code) to get this to
work?

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size() method is
called as part of the getViewSize() in the AbstractPageableView. Thus I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20702476.html
Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

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. I'm only interested in displaying say the
first 10 rows. Then the user can click on load next 10 and thus display
the next 'page' of results. They then have a choice of loading the next 10
or the previous 10, etc. Perhaps DataView is not really suited to this type
of behaviour? more used where you want to see the number of pages a search
result finds for example? If we're at the edge condition that there are
exactly 20 results, when asking for the next 10, we simply disply the
message 'no more results'.

We just issue a count(*) query first to get the count
Yes so this will be called every time the page is rendered no unless you
cache as you stated, but you run the risk changing dataset?

thanks
Wayne

On Wed, Nov 26, 2008 at 5:05 PM, James Carman [EMAIL PROTECTED]wrote:

On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:

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 pagable/provider code (not looked at the code) to get this to
work?

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 b) call count on the Db , then load
in
the iterator mehod. Thats going to kill the database in prod (or really
not
help.)

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size() method
is
called as part of the getViewSize() in the AbstractPageableView. Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice
for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Matej Knopp

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 number of rows upfront.

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.

-Matej

On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
[EMAIL PROTECTED] wrote:
Hi James,

We just issue a count(*) query first to get the count
Yes so this will be called every time the page is rendered no unless you
cache as you stated, but you run the risk changing dataset?

thanks
Wayne

On Wed, Nov 26, 2008 at 5:05 PM, James Carman [EMAIL PROTECTED]wrote:

On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:

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 pagable/provider code (not looked at the code) to get this to
work?

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 b) call count on the Db , then load
in
the iterator mehod. Thats going to kill the database in prod (or really
not
help.)

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size() method
is
called as part of the getViewSize() in the AbstractPageableView. Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice
for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread James Carman

Or there's that! :)

On Wed, Nov 26, 2008 at 11:21 AM, Matej Knopp [EMAIL PROTECTED] wrote:

Hi Wayne,

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.

-Matej

On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
[EMAIL PROTECTED] wrote:
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. I'm only interested in displaying say
the
first 10 rows. Then the user can click on load next 10 and thus display
the next 'page' of results. They then have a choice of loading the next
10
or the previous 10, etc. Perhaps DataView is not really suited to this
type
of behaviour? more used where you want to see the number of pages a
search
result finds for example? If we're at the edge condition that there are
exactly 20 results, when asking for the next 10, we simply disply the
message 'no more results'.

We just issue a count(*) query first to get the count
Yes so this will be called every time the page is rendered no unless you
cache as you stated, but you run the risk changing dataset?

thanks
Wayne

On Wed, Nov 26, 2008 at 5:05 PM, James Carman
[EMAIL PROTECTED]wrote:

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 gets called, really). If calling the queries to get the individual
page's data is killing your database, then you're doing something wrong,
IMHO.

On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:

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 pagable/provider code (not looked at the code) to get this
to
work?

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 b) call count on the Db , then
load
in
the iterator mehod. Thats going to kill the database in prod (or
really
not
help.)

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer
[EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size()
method
is
called as part of the getViewSize() in the AbstractPageableView.
Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice
for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way
?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

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 about telling the user the total amount of rows.

Thanks everyone for your comments and help
Wayne

On Wed, Nov 26, 2008 at 5:21 PM, Matej Knopp [EMAIL PROTECTED] wrote:

Hi Wayne,

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.

-Matej

On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
[EMAIL PROTECTED] wrote:
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. I'm only interested in displaying say
the
first 10 rows. Then the user can click on load next 10 and thus display
the next 'page' of results. They then have a choice of loading the next
10
or the previous 10, etc. Perhaps DataView is not really suited to this
type
of behaviour? more used where you want to see the number of pages a
search
result finds for example? If we're at the edge condition that there are
exactly 20 results, when asking for the next 10, we simply disply the
message 'no more results'.

We just issue a count(*) query first to get the count
Yes so this will be called every time the page is rendered no unless you
cache as you stated, but you run the risk changing dataset?

thanks
Wayne

On Wed, Nov 26, 2008 at 5:05 PM, James Carman
[EMAIL PROTECTED]wrote:

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 gets called, really). If calling the queries to get the individual
page's data is killing your database, then you're doing something wrong,
IMHO.

On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:

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 pagable/provider code (not looked at the code) to get this
to
work?

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 b) call count on the Db , then
load
in
the iterator mehod. Thats going to kill the database in prod (or
really
not
help.)

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer
[EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size()
method
is
called as part of the getViewSize() in the AbstractPageableView.
Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice
for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way
?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Matej Knopp

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 one row more than required on page which
tells the grid if there will be a next page or not.

Thanks everyone for your comments and help
Wayne

On Wed, Nov 26, 2008 at 5:21 PM, Matej Knopp [EMAIL PROTECTED] wrote:

Hi Wayne,

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.

-Matej

On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
[EMAIL PROTECTED] wrote:
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. I'm only interested in displaying say
the
first 10 rows. Then the user can click on load next 10 and thus display
the next 'page' of results. They then have a choice of loading the next
10
or the previous 10, etc. Perhaps DataView is not really suited to this
type
of behaviour? more used where you want to see the number of pages a
search
result finds for example? If we're at the edge condition that there are
exactly 20 results, when asking for the next 10, we simply disply the
message 'no more results'.

We just issue a count(*) query first to get the count
Yes so this will be called every time the page is rendered no unless you
cache as you stated, but you run the risk changing dataset?

thanks
Wayne

On Wed, Nov 26, 2008 at 5:05 PM, James Carman
[EMAIL PROTECTED]wrote:

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 gets called, really). If calling the queries to get the individual
page's data is killing your database, then you're doing something wrong,
IMHO.

On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope
[EMAIL PROTECTED] wrote:

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 pagable/provider code (not looked at the code) to get this
to
work?

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 b) call count on the Db , then
load
in
the iterator mehod. Thats going to kill the database in prod (or
really
not
help.)

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer
[EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size()
method
is
called as part of the getViewSize() in the AbstractPageableView.
Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice
for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way
?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Igor Vaynberg

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. Thats going to kill the database in prod (or really not
help.)

-igor

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]wrote:

have a look at https://issues.apache.org/jira/browse/WICKET-1784

Wayne Pope-2 wrote:

Ok,

Am I doing sonething wrong or have I got to hit the database twice for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread James Carman

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
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. Thats going to kill the database in prod (or really
not
help.)

-igor

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size() method
is
called as part of the getViewSize() in the AbstractPageableView. Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

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 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 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 about telling the user the total amount of rows.
 
  Thanks everyone for your comments and help
  Wayne
 
  On Wed, Nov 26, 2008 at 5:21 PM, 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 branch). The grid contains AbstractPageableView that can
  perform paging without having to know the number of rows upfront.
 
  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.
 
  -Matej
 
  On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
  [EMAIL PROTECTED] wrote:
   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. I'm only interested in displaying say
  the
   first 10 rows. Then the user can click on load next 10 and thus
 display
   the next 'page' of results. They then have a choice of loading the
 next
  10
   or the previous 10, etc. Perhaps DataView is not really suited to this
  type
   of behaviour? more used where you want to see the number of pages a
  search
   result finds for example? If we're at the edge condition that there
 are
   exactly 20 results, when asking for the next 10, we simply disply the
   message 'no more results'.
  
  
  We just issue a count(*) query first to get the count
   Yes so this will be called every time the page is rendered no unless
 you
   cache as you stated, but you run the risk changing dataset?
  
   thanks
   Wayne
  
   On Wed, Nov 26, 2008 at 5:05 PM, James Carman 
  [EMAIL PROTECTED]wrote:
  
   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 gets called, really).  If calling the queries to get the
 individual
   page's data is killing your database, then you're doing something
 wrong,
   IMHO.
  
   On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
   [EMAIL PROTECTED] wrote:
  
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 pagable/provider code (not looked at the code) to get
 this
  to
work?
   
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 b) call count on the Db , then
  load
   in
the iterator mehod. Thats going to kill the database in prod (or
  really
   not
help.)
   
On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer 
  [EMAIL PROTECTED]
wrote:
   

 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
the
  offset). Great I thought - however I see that that the size()
  method
   is
  called as part of the getViewSize() in the
 AbstractPageableView.
  Thus
   I
  need
  to call the database here to figure out the size.
 
  Am I doing sonething wrong or have I got to hit the database
 twice
   for
  each
  DataProvider render.
 
  Obvously I don't want to hard code a size. Is there any other
 way
  ?
 
  Thanks
  Wayne
 
 


 -
 Michael Sparer
 http://talk-on-tech.blogspot.com
 --
 View this message in

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

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.

Ouch.
I just want to limit calls if possible to the database as waiting for i/o's
is never great for scalability. I'm not 'having a go' at wicket or DataViews
or anything, just trying to understand it. I never claimed to be a guru -
far from it.

Wayne

On Wed, Nov 26, 2008 at 5:58 PM, 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
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. Thats going to kill the database in prod (or really
not
help.)

-igor

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size() method
is
called as part of the getViewSize() in the AbstractPageableView. Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Igor Vaynberg

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 the network is actually
more efficient then doing another query wtf.

Ouch.
I just want to limit calls if possible to the database as waiting for i/o's
is never great for scalability. I'm not 'having a go' at wicket or DataViews
or anything, just trying to understand it. I never claimed to be a guru -
far from it.

-igor

Wayne

On Wed, Nov 26, 2008 at 5:58 PM, 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
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. Thats going to kill the database in prod (or really
not
help.)

-igor

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer [EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size() method
is
called as part of the getViewSize() in the AbstractPageableView. Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

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.

No I haven't, as mentioned before, I just want to avoid 2 calls when one
will do. I have however seen several times in production systems waiting on
i/o's reduces your scalability. I'd rather keep server count down as money
is tight.
I'll be mindfull not to ask 'stupid' questions again.

On Wed, Nov 26, 2008 at 6:19 PM, Igor Vaynberg [EMAIL PROTECTED]wrote:

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 the network is actually
more efficient then doing another query wtf.

-igor

Wayne

On Wed, Nov 26, 2008 at 5:58 PM, 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
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. Thats going to kill the database in prod (or
really
not
help.)

-igor

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer
[EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size()
method
is
called as part of the getViewSize() in the AbstractPageableView.
Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice
for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread András Csáki

 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 preceding
and unbounded following ) cnt
from (
  select 1 data from dual
  union
  select 2 data from dual
)


Andras

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Igor Vaynberg

the number of calls itself is meaningless, i dont comprehend why
people have a hard time understanding this simple fact.

-igor

No I haven't, as mentioned before, I just want to avoid 2 calls when one
will do. I have however seen several times in production systems waiting on
i/o's reduces your scalability. I'd rather keep server count down as money
is tight.
I'll be mindfull not to ask 'stupid' questions again.

On Wed, Nov 26, 2008 at 6:19 PM, Igor Vaynberg [EMAIL PROTECTED]wrote:

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 the network is actually
more efficient then doing another query wtf.

-igor

Wayne

On Wed, Nov 26, 2008 at 5:58 PM, 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
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. Thats going to kill the database in prod (or
really
not
help.)

-igor

On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer
[EMAIL PROTECTED]
wrote:

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
the
offset). Great I thought - however I see that that the size()
method
is
called as part of the getViewSize() in the AbstractPageableView.
Thus
I
need
to call the database here to figure out the size.

Am I doing sonething wrong or have I got to hit the database twice
for
each
DataProvider render.

Obvously I don't want to hard code a size. Is there any other way ?

Thanks
Wayne

-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

 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()
followed by
select firstName,lastName from user user1 inner join company com1 on
user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20 - called
in iterator


is going to cost more than just:
select firstName,lastName from user user1 inner join company com1 on
user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20
which is all that is needed

hence avoiding 2 calls where 1 will do.

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread jWeekend


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 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 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 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 about telling the user the total amount of rows.
 
  Thanks everyone for your comments and help
  Wayne
 
  On Wed, Nov 26, 2008 at 5:21 PM, 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 branch). The grid contains AbstractPageableView that can
  perform paging without having to know the number of rows upfront.
 
  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.
 
  -Matej
 
  On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope
  [EMAIL PROTECTED] wrote:
   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. I'm only interested in displaying
 say
  the
   first 10 rows. Then the user can click on load next 10 and thus
 display
   the next 'page' of results. They then have a choice of loading the
 next
  10
   or the previous 10, etc. Perhaps DataView is not really suited to
 this
  type
   of behaviour? more used where you want to see the number of pages a
  search
   result finds for example? If we're at the edge condition that there
 are
   exactly 20 results, when asking for the next 10, we simply disply
 the
   message 'no more results'.
  
  
  We just issue a count(*) query first to get the count
   Yes so this will be called every time the page is rendered no unless
 you
   cache as you stated, but you run the risk changing dataset?
  
   thanks
   Wayne
  
   On Wed, Nov 26, 2008 at 5:05 PM, James Carman 
  [EMAIL PROTECTED]wrote:
  
   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 gets called, really).  If calling the queries to get the
 individual
   page's data is killing your database, then you're doing something
 wrong,
   IMHO.
  
   On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope 
   [EMAIL PROTECTED] wrote:
  
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 pagable/provider code (not looked at the code) to get
 this
  to
work?
   
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 b) call count on the Db ,
 then
  load
   in
the iterator mehod. Thats going to kill the database in prod (or
  really
   not
help.)
   
On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer 
  [EMAIL PROTECTED]
wrote:
   

 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
the
  offset). Great I thought - however I see that that the size()
  method
   is
  called as part of the getViewSize() in the
 AbstractPageableView.
  Thus
   I
  need
  to call the database here to figure out the size.
 
  Am I doing sonething wrong or have I got to hit the database
 twice
   for
  each
  DataProvider render.

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Jeremy Thomerson

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
needed (ala inmethod).

A count call will be very quick.  And it transfers minimal data.

On Wed, Nov 26, 2008 at 12:45 PM, Wayne Pope 
[EMAIL PROTECTED] wrote:

  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()
 followed by
 select firstName,lastName from user user1 inner join company com1 on
 user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20 -
 called
 in iterator


 is going to cost more than just:
 select firstName,lastName from user user1 inner join company com1 on
 user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20
 which is all that is needed

 hence avoiding 2 calls where 1 will do.




-- 
Jeremy Thomerson
http://www.wickettraining.com

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread Wayne Pope

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
 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
 needed (ala inmethod).

 A count call will be very quick.  And it transfers minimal data.

 On Wed, Nov 26, 2008 at 12:45 PM, Wayne Pope 
 [EMAIL PROTECTED] wrote:

   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()
  followed by
  select firstName,lastName from user user1 inner join company com1 on
  user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20 -
  called
  in iterator
 
 
  is going to cost more than just:
  select firstName,lastName from user user1 inner join company com1 on
  user1.company_id=com1.id where com1.code='dht2' limit 10 offset 20
  which is all that is needed
 
  hence avoiding 2 calls where 1 will do.
 



 --
 Jeremy Thomerson
 http://www.wickettraining.com

RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

2008-11-26 Thread rgoodwin


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 on day one of using
Wicket. But pain is experienced later when encountering the Wicket data
provision and paging mechanism coupling. The paging mechanism is far less
joy to replace ...

IReallyHateDataProvider



Hoover, William wrote:
 
 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 support getting the size/results in one call), but the last time I
 brought this issue up it was disputed.
 

-- 
View this message in context: 
http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20708929.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets

29 matches

Site Navigation

Mail list logo

Footer information