RE: DataView size() iterator() call order issue
I apologize that I missed the detach() portion of your email :o)
I don't want to beat the issue on needing size before offset/count and waste
anymore of anyone's time. In a legacy application we have I already
accomplished this. So, I will just use some customization to the wicket
components and incorporate the code from the legacy JSF application. Thanks for
your time!
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2008 8:59 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
i already mentioned detach() in my fist reply to this thread 2 days ago...
and as i said before both variables that go into the iterator() are
depending on the size call so the size() call really needs to happen first
or we have to just guess those 2 variables completely
johan
On Fri, Mar 28, 2008 at 1:23 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> Perfect! detach was the missing piece of the puzzle, thank you! The only
> issue remaining is the capability to combine the size/iterator call to
> prevent duplicate DAO calls.
>
> -Original Message-
> From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2008 12:02 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> forgot:
>
> public class MYSizeCachingDataProvider ... {
>public void detach() {
>size = null;
>resultset = null;
>}
> }
>
>
> On 3/27/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > public class MySizeCachingDataProvider implements IDataProvider {
> > private Integer size = null;
> > private List resultset = null;
> > public int getSize() {
> > if(size == null ) {
> > performExpensiveQuery();
> > }
> > return size;
> > }
> > public Iterator iterator() {
> > if(resultset == null ) {
> > performExpensiveQuery();
> > }
> > return resultset;
> > }
> > private void performExpensiveQuery() {
> > size = count();
> > resultset = query();
> >
> > }
> > }
> >
> > On 3/27/08, Hoover, William <[EMAIL PROTECTED]> wrote:
> > > I'm only interested in caching it for the current request so there
> isn't multiple calls to size within the same request. The same way
> AbstractPageableView is caching it and clearing it in "onBeforeRender". The
> only problem is that:
> > >
> > > 1) I do not have access to the cached size stored in
> AbstractPageableView -> cachedItemCount from within the data provider
> > > 2) The cached size in AbstractPageableView -> cachedItemCount is
> "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
> models in getItemModels(); This causes a second call to the data providers
> size() method when paginating. In other words, the AbstractPageableView ->
> cachedItemCount is not working properly when a link for the PagingNavigator
> is clicked- causing 2 calls to the size() method within the same request
> (w/o deletions ;o).
> > >
> > >
> > > -Original Message-
> > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > >
> > > Sent: Thursday, March 27, 2008 11:36 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > If you are iterating over a list that can be changed by all kinds of
> > > different users
> > > Then you cant really cache it
> > >
> > > If you are iterating over a list that is pretty stable for the
> current users
> > > or the user itself only alters that list (insert/delete)
> > > Then you can cache it easily
> > >
> > > Just call detach (that clears the size cache) when you have an
> action that
> > > deletes or inserts a new items so that you know the size is changed.
> > >
> > > johan
> > >
> > >
> > > On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <
> [EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Can you post code for an example data provider that would KNOW how
> to
> > > > cache the size?
> > > >
> > > > -Original Message-
> > > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, March 27, 2008 10
Re: DataView size() iterator() call order issue
i already mentioned detach() in my fist reply to this thread 2 days ago...
and as i said before both variables that go into the iterator() are
depending on the size call so the size() call really needs to happen first
or we have to just guess those 2 variables completely
johan
On Fri, Mar 28, 2008 at 1:23 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> Perfect! detach was the missing piece of the puzzle, thank you! The only
> issue remaining is the capability to combine the size/iterator call to
> prevent duplicate DAO calls.
>
> -Original Message-
> From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2008 12:02 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> forgot:
>
> public class MYSizeCachingDataProvider ... {
>public void detach() {
>size = null;
>resultset = null;
>}
> }
>
>
> On 3/27/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > public class MySizeCachingDataProvider implements IDataProvider {
> > private Integer size = null;
> > private List resultset = null;
> > public int getSize() {
> > if(size == null ) {
> > performExpensiveQuery();
> > }
> > return size;
> > }
> > public Iterator iterator() {
> > if(resultset == null ) {
> > performExpensiveQuery();
> > }
> > return resultset;
> > }
> > private void performExpensiveQuery() {
> > size = count();
> > resultset = query();
> >
> > }
> > }
> >
> > On 3/27/08, Hoover, William <[EMAIL PROTECTED]> wrote:
> > > I'm only interested in caching it for the current request so there
> isn't multiple calls to size within the same request. The same way
> AbstractPageableView is caching it and clearing it in "onBeforeRender". The
> only problem is that:
> > >
> > > 1) I do not have access to the cached size stored in
> AbstractPageableView -> cachedItemCount from within the data provider
> > > 2) The cached size in AbstractPageableView -> cachedItemCount is
> "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
> models in getItemModels(); This causes a second call to the data providers
> size() method when paginating. In other words, the AbstractPageableView ->
> cachedItemCount is not working properly when a link for the PagingNavigator
> is clicked- causing 2 calls to the size() method within the same request
> (w/o deletions ;o).
> > >
> > >
> > > -Original Message-
> > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > >
> > > Sent: Thursday, March 27, 2008 11:36 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > If you are iterating over a list that can be changed by all kinds of
> > > different users
> > > Then you cant really cache it
> > >
> > > If you are iterating over a list that is pretty stable for the
> current users
> > > or the user itself only alters that list (insert/delete)
> > > Then you can cache it easily
> > >
> > > Just call detach (that clears the size cache) when you have an
> action that
> > > deletes or inserts a new items so that you know the size is changed.
> > >
> > > johan
> > >
> > >
> > > On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <
> [EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Can you post code for an example data provider that would KNOW how
> to
> > > > cache the size?
> > > >
> > > > -Original Message-
> > > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, March 27, 2008 10:47 AM
> > > > To: users@wicket.apache.org
> > > > Subject: Re: DataView size() iterator() call order issue
> > > >
> > > >
> > > > no you as a developer KNOW that it can cache it
> > > > Cache it if you can dont if you cant
> > > >
> > > > On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <
> [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Okay, two issues... (1) combined call for size/data (2) multiple
&
RE: DataView size() iterator() call order issue
Perfect! detach was the missing piece of the puzzle, thank you! The only issue
remaining is the capability to combine the size/iterator call to prevent
duplicate DAO calls.
-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 12:02 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
forgot:
public class MYSizeCachingDataProvider ... {
public void detach() {
size = null;
resultset = null;
}
}
On 3/27/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> public class MySizeCachingDataProvider implements IDataProvider {
> private Integer size = null;
> private List resultset = null;
> public int getSize() {
> if(size == null ) {
> performExpensiveQuery();
> }
> return size;
> }
> public Iterator iterator() {
> if(resultset == null ) {
> performExpensiveQuery();
> }
> return resultset;
> }
> private void performExpensiveQuery() {
> size = count();
> resultset = query();
>
> }
> }
>
> On 3/27/08, Hoover, William <[EMAIL PROTECTED]> wrote:
> > I'm only interested in caching it for the current request so there isn't
> multiple calls to size within the same request. The same way
> AbstractPageableView is caching it and clearing it in "onBeforeRender". The
> only problem is that:
> >
> > 1) I do not have access to the cached size stored in AbstractPageableView
> -> cachedItemCount from within the data provider
> > 2) The cached size in AbstractPageableView -> cachedItemCount is
> "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
> models in getItemModels(); This causes a second call to the data providers
> size() method when paginating. In other words, the AbstractPageableView ->
> cachedItemCount is not working properly when a link for the PagingNavigator
> is clicked- causing 2 calls to the size() method within the same request (w/o
> deletions ;o).
> >
> >
> > -Original Message-----
> > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> >
> > Sent: Thursday, March 27, 2008 11:36 AM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > If you are iterating over a list that can be changed by all kinds of
> > different users
> > Then you cant really cache it
> >
> > If you are iterating over a list that is pretty stable for the current
> users
> > or the user itself only alters that list (insert/delete)
> > Then you can cache it easily
> >
> > Just call detach (that clears the size cache) when you have an action that
> > deletes or inserts a new items so that you know the size is changed.
> >
> > johan
> >
> >
> > On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Can you post code for an example data provider that would KNOW how to
> > > cache the size?
> > >
> > > -Original Message-
> > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, March 27, 2008 10:47 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > no you as a developer KNOW that it can cache it
> > > Cache it if you can dont if you cant
> > >
> > > On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Okay, two issues... (1) combined call for size/data (2) multiple calls
> > > to
> > > > size() when paginating
> > > >
> > > > I will avoid confusion by addressing only the multiple calls to size()
> > > for
> > > > now.
> > > >
> > > > If only the size was to be cached, as you suggested, how would the
> data
> > > > provider know when to clear it? The data provider is statefull and
> > > maintains
> > > > the size across requests and there is no "onBeforeRender" in a data
> > > provider
> > > > like there is in AbstractPageableView. So, the size will never be
> > > cleared
> > > > when paginating from one page to the next. Even if we were able to
> cache
> > > the
>
Re: DataView size() iterator() call order issue
forgot:
public class MYSizeCachingDataProvider ... {
public void detach() {
size = null;
resultset = null;
}
}
On 3/27/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> public class MySizeCachingDataProvider implements IDataProvider {
> private Integer size = null;
> private List resultset = null;
> public int getSize() {
> if(size == null ) {
> performExpensiveQuery();
> }
> return size;
> }
> public Iterator iterator() {
> if(resultset == null ) {
> performExpensiveQuery();
> }
> return resultset;
> }
> private void performExpensiveQuery() {
> size = count();
> resultset = query();
>
> }
> }
>
> On 3/27/08, Hoover, William <[EMAIL PROTECTED]> wrote:
> > I'm only interested in caching it for the current request so there isn't
> multiple calls to size within the same request. The same way
> AbstractPageableView is caching it and clearing it in "onBeforeRender". The
> only problem is that:
> >
> > 1) I do not have access to the cached size stored in AbstractPageableView
> -> cachedItemCount from within the data provider
> > 2) The cached size in AbstractPageableView -> cachedItemCount is
> "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
> models in getItemModels(); This causes a second call to the data providers
> size() method when paginating. In other words, the AbstractPageableView ->
> cachedItemCount is not working properly when a link for the PagingNavigator
> is clicked- causing 2 calls to the size() method within the same request (w/o
> deletions ;o).
> >
> >
> > -Original Message-----
> > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> >
> > Sent: Thursday, March 27, 2008 11:36 AM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > If you are iterating over a list that can be changed by all kinds of
> > different users
> > Then you cant really cache it
> >
> > If you are iterating over a list that is pretty stable for the current
> users
> > or the user itself only alters that list (insert/delete)
> > Then you can cache it easily
> >
> > Just call detach (that clears the size cache) when you have an action that
> > deletes or inserts a new items so that you know the size is changed.
> >
> > johan
> >
> >
> > On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Can you post code for an example data provider that would KNOW how to
> > > cache the size?
> > >
> > > -Original Message-
> > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, March 27, 2008 10:47 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > no you as a developer KNOW that it can cache it
> > > Cache it if you can dont if you cant
> > >
> > > On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Okay, two issues... (1) combined call for size/data (2) multiple calls
> > > to
> > > > size() when paginating
> > > >
> > > > I will avoid confusion by addressing only the multiple calls to size()
> > > for
> > > > now.
> > > >
> > > > If only the size was to be cached, as you suggested, how would the
> data
> > > > provider know when to clear it? The data provider is statefull and
> > > maintains
> > > > the size across requests and there is no "onBeforeRender" in a data
> > > provider
> > > > like there is in AbstractPageableView. So, the size will never be
> > > cleared
> > > > when paginating from one page to the next. Even if we were able to
> cache
> > > the
> > > > size we would be maintaining the same data in two different locations-
> > > in
> > > > the AbstractPageableView -> cachedItemCount and in the data provider.
> > > >
> > > > -Original Message-
> > > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > Sent: Th
Re: DataView size() iterator() call order issue
public class MySizeCachingDataProvider implements IDataProvider {
private Integer size = null;
private List resultset = null;
public int getSize() {
if(size == null ) {
performExpensiveQuery();
}
return size;
}
public Iterator iterator() {
if(resultset == null ) {
performExpensiveQuery();
}
return resultset;
}
private void performExpensiveQuery() {
size = count();
resultset = query();
}
}
On 3/27/08, Hoover, William <[EMAIL PROTECTED]> wrote:
> I'm only interested in caching it for the current request so there isn't
> multiple calls to size within the same request. The same way
> AbstractPageableView is caching it and clearing it in "onBeforeRender". The
> only problem is that:
>
> 1) I do not have access to the cached size stored in AbstractPageableView ->
> cachedItemCount from within the data provider
> 2) The cached size in AbstractPageableView -> cachedItemCount is "cleared"
> in onBeforeRender() before the call is made to getViewOffset() ->
> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
> models in getItemModels(); This causes a second call to the data providers
> size() method when paginating. In other words, the AbstractPageableView ->
> cachedItemCount is not working properly when a link for the PagingNavigator
> is clicked- causing 2 calls to the size() method within the same request (w/o
> deletions ;o).
>
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
>
> Sent: Thursday, March 27, 2008 11:36 AM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> If you are iterating over a list that can be changed by all kinds of
> different users
> Then you cant really cache it
>
> If you are iterating over a list that is pretty stable for the current users
> or the user itself only alters that list (insert/delete)
> Then you can cache it easily
>
> Just call detach (that clears the size cache) when you have an action that
> deletes or inserts a new items so that you know the size is changed.
>
> johan
>
>
> On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>
> > Can you post code for an example data provider that would KNOW how to
> > cache the size?
> >
> > -----Original Message-
> > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 27, 2008 10:47 AM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > no you as a developer KNOW that it can cache it
> > Cache it if you can dont if you cant
> >
> > On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Okay, two issues... (1) combined call for size/data (2) multiple calls
> > to
> > > size() when paginating
> > >
> > > I will avoid confusion by addressing only the multiple calls to size()
> > for
> > > now.
> > >
> > > If only the size was to be cached, as you suggested, how would the data
> > > provider know when to clear it? The data provider is statefull and
> > maintains
> > > the size across requests and there is no "onBeforeRender" in a data
> > provider
> > > like there is in AbstractPageableView. So, the size will never be
> > cleared
> > > when paginating from one page to the next. Even if we were able to cache
> > the
> > > size we would be maintaining the same data in two different locations-
> > in
> > > the AbstractPageableView -> cachedItemCount and in the data provider.
> > >
> > > -Original Message-
> > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, March 27, 2008 8:12 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > no cache the size.
> > > We first have to have the size to be able to give you the offset and
> > count
> > > params.
> > > And depending of the type of data or the database you use you could also
> > > already query the data (in the size() call)
> > > But i know that is not always the best thing to do.
> > >
> > > But do you want an extra 2 params also in the size() call?
> > > What would be the offset and what would be the max length?
> > > The problem is that both
RE: DataView size() iterator() call order issue
I'm only interested in caching it for the current request so there isn't multiple calls to size within the same request. The same way AbstractPageableView is caching it and clearing it in "onBeforeRender". The only problem is that: 1) I do not have access to the cached size stored in AbstractPageableView -> cachedItemCount from within the data provider 2) The cached size in AbstractPageableView -> cachedItemCount is "cleared" in onBeforeRender() before the call is made to getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item models in getItemModels(); This causes a second call to the data providers size() method when paginating. In other words, the AbstractPageableView -> cachedItemCount is not working properly when a link for the PagingNavigator is clicked- causing 2 calls to the size() method within the same request (w/o deletions ;o). -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 11:36 AM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue If you are iterating over a list that can be changed by all kinds of different users Then you cant really cache it If you are iterating over a list that is pretty stable for the current users or the user itself only alters that list (insert/delete) Then you can cache it easily Just call detach (that clears the size cache) when you have an action that deletes or inserts a new items so that you know the size is changed. johan On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > Can you post code for an example data provider that would KNOW how to > cache the size? > > -Original Message- > From: Johan Compagner [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2008 10:47 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > > no you as a developer KNOW that it can cache it > Cache it if you can dont if you cant > > On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > > Okay, two issues... (1) combined call for size/data (2) multiple calls > to > > size() when paginating > > > > I will avoid confusion by addressing only the multiple calls to size() > for > > now. > > > > If only the size was to be cached, as you suggested, how would the data > > provider know when to clear it? The data provider is statefull and > maintains > > the size across requests and there is no "onBeforeRender" in a data > provider > > like there is in AbstractPageableView. So, the size will never be > cleared > > when paginating from one page to the next. Even if we were able to cache > the > > size we would be maintaining the same data in two different locations- > in > > the AbstractPageableView -> cachedItemCount and in the data provider. > > > > -Original Message- > > From: Johan Compagner [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 27, 2008 8:12 AM > > To: users@wicket.apache.org > > Subject: Re: DataView size() iterator() call order issue > > > > > > no cache the size. > > We first have to have the size to be able to give you the offset and > count > > params. > > And depending of the type of data or the database you use you could also > > already query the data (in the size() call) > > But i know that is not always the best thing to do. > > > > But do you want an extra 2 params also in the size() call? > > What would be the offset and what would be the max length? > > The problem is that both of those depends on the size call. > > So the offset is calculated with the size param as is the count.. > > > > So if we try to guess those 2 params for the size() call then those 2 > > params > > dont have to be the same for the iterator call... > > > > johan > > > > > > On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]> > > wrote: > > > > > Also, you mention that all that is needed is to cache it (I assume you > > are > > > referring to the actual data) in the data provider. How can that be > done > > > when the size is being called when there is no way to get the current > > offset > > > that is needed to get the data in the first place? > > > > > > -Original Message- > > > From: Hoover, William [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 27, 2008 7:55 AM > > > To: users@wicket.apache.org > > > Subject: RE: DataView size() iterator() call order issue > > > > > > >
Re: DataView size() iterator() call order issue
If you are iterating over a list that can be changed by all kinds of different users Then you cant really cache it If you are iterating over a list that is pretty stable for the current users or the user itself only alters that list (insert/delete) Then you can cache it easily Just call detach (that clears the size cache) when you have an action that deletes or inserts a new items so that you know the size is changed. johan On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > Can you post code for an example data provider that would KNOW how to > cache the size? > > -Original Message- > From: Johan Compagner [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2008 10:47 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > > no you as a developer KNOW that it can cache it > Cache it if you can dont if you cant > > On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > > Okay, two issues... (1) combined call for size/data (2) multiple calls > to > > size() when paginating > > > > I will avoid confusion by addressing only the multiple calls to size() > for > > now. > > > > If only the size was to be cached, as you suggested, how would the data > > provider know when to clear it? The data provider is statefull and > maintains > > the size across requests and there is no "onBeforeRender" in a data > provider > > like there is in AbstractPageableView. So, the size will never be > cleared > > when paginating from one page to the next. Even if we were able to cache > the > > size we would be maintaining the same data in two different locations- > in > > the AbstractPageableView -> cachedItemCount and in the data provider. > > > > -----Original Message----- > > From: Johan Compagner [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 27, 2008 8:12 AM > > To: users@wicket.apache.org > > Subject: Re: DataView size() iterator() call order issue > > > > > > no cache the size. > > We first have to have the size to be able to give you the offset and > count > > params. > > And depending of the type of data or the database you use you could also > > already query the data (in the size() call) > > But i know that is not always the best thing to do. > > > > But do you want an extra 2 params also in the size() call? > > What would be the offset and what would be the max length? > > The problem is that both of those depends on the size call. > > So the offset is calculated with the size param as is the count.. > > > > So if we try to guess those 2 params for the size() call then those 2 > > params > > dont have to be the same for the iterator call... > > > > johan > > > > > > On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]> > > wrote: > > > > > Also, you mention that all that is needed is to cache it (I assume you > > are > > > referring to the actual data) in the data provider. How can that be > done > > > when the size is being called when there is no way to get the current > > offset > > > that is needed to get the data in the first place? > > > > > > -Original Message- > > > From: Hoover, William [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 27, 2008 7:55 AM > > > To: users@wicket.apache.org > > > Subject: RE: DataView size() iterator() call order issue > > > > > > > > > The difference is that in the deletion scenario the state of the data > > has > > > changed. In the pagination scenario the state of the data has not > > changed. > > > Why is that so difficult to differentiate? > > > > > > -Original Message- > > > From: Johan Compagner [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 27, 2008 7:49 AM > > > To: users@wicket.apache.org > > > Subject: Re: DataView size() iterator() call order issue > > > > > > > > > and how do we know the difference? > > > > > > You as a developer know it, we dont know it as a framework, just cache > > it > > > in > > > your dataprovider or wrap in in a caching data provider. Why is that > so > > > difficult > > > > > > johan > > > > > > > > > On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED] > > > > > wrote: > > > > > > > That makes perfect sense in the scenario where rows are d
RE: DataView size() iterator() call order issue
Can you post code for an example data provider that would KNOW how to cache the size? -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 10:47 AM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue no you as a developer KNOW that it can cache it Cache it if you can dont if you cant On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > Okay, two issues... (1) combined call for size/data (2) multiple calls to > size() when paginating > > I will avoid confusion by addressing only the multiple calls to size() for > now. > > If only the size was to be cached, as you suggested, how would the data > provider know when to clear it? The data provider is statefull and maintains > the size across requests and there is no "onBeforeRender" in a data provider > like there is in AbstractPageableView. So, the size will never be cleared > when paginating from one page to the next. Even if we were able to cache the > size we would be maintaining the same data in two different locations- in > the AbstractPageableView -> cachedItemCount and in the data provider. > > -Original Message- > From: Johan Compagner [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2008 8:12 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > > no cache the size. > We first have to have the size to be able to give you the offset and count > params. > And depending of the type of data or the database you use you could also > already query the data (in the size() call) > But i know that is not always the best thing to do. > > But do you want an extra 2 params also in the size() call? > What would be the offset and what would be the max length? > The problem is that both of those depends on the size call. > So the offset is calculated with the size param as is the count.. > > So if we try to guess those 2 params for the size() call then those 2 > params > dont have to be the same for the iterator call... > > johan > > > On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > > Also, you mention that all that is needed is to cache it (I assume you > are > > referring to the actual data) in the data provider. How can that be done > > when the size is being called when there is no way to get the current > offset > > that is needed to get the data in the first place? > > > > -----Original Message- > > From: Hoover, William [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 27, 2008 7:55 AM > > To: users@wicket.apache.org > > Subject: RE: DataView size() iterator() call order issue > > > > > > The difference is that in the deletion scenario the state of the data > has > > changed. In the pagination scenario the state of the data has not > changed. > > Why is that so difficult to differentiate? > > > > -Original Message- > > From: Johan Compagner [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 27, 2008 7:49 AM > > To: users@wicket.apache.org > > Subject: Re: DataView size() iterator() call order issue > > > > > > and how do we know the difference? > > > > You as a developer know it, we dont know it as a framework, just cache > it > > in > > your dataprovider or wrap in in a caching data provider. Why is that so > > difficult > > > > johan > > > > > > On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]> > > wrote: > > > > > That makes perfect sense in the scenario where rows are deleted, but > it > > > doesn't make sense when all that is being done is clicking the next > > button > > > for a PagingNavigator. Why would do we need two calls to the size > method > > in > > > that scenario? > > > > > > -Original Message- > > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 26, 2008 3:27 PM > > > To: users@wicket.apache.org > > > Subject: Re: DataView size() iterator() call order issue > > > > > > > > > On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED] > > > > > wrote: > > > > 2) Although AbstractPageableView does ensure the cached item count > is > > > used before calling the data provider size() in getRowCount(), the > > cached > > > item count is "cleared" in onBeforeRender() before the call is made to > > > getViewOffset() -> getCurrentPage() -> getPageCount() -&
Re: DataView size() iterator() call order issue
no you as a developer KNOW that it can cache it Cache it if you can dont if you cant On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > Okay, two issues... (1) combined call for size/data (2) multiple calls to > size() when paginating > > I will avoid confusion by addressing only the multiple calls to size() for > now. > > If only the size was to be cached, as you suggested, how would the data > provider know when to clear it? The data provider is statefull and maintains > the size across requests and there is no "onBeforeRender" in a data provider > like there is in AbstractPageableView. So, the size will never be cleared > when paginating from one page to the next. Even if we were able to cache the > size we would be maintaining the same data in two different locations- in > the AbstractPageableView -> cachedItemCount and in the data provider. > > -Original Message- > From: Johan Compagner [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2008 8:12 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > > no cache the size. > We first have to have the size to be able to give you the offset and count > params. > And depending of the type of data or the database you use you could also > already query the data (in the size() call) > But i know that is not always the best thing to do. > > But do you want an extra 2 params also in the size() call? > What would be the offset and what would be the max length? > The problem is that both of those depends on the size call. > So the offset is calculated with the size param as is the count.. > > So if we try to guess those 2 params for the size() call then those 2 > params > dont have to be the same for the iterator call... > > johan > > > On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > > Also, you mention that all that is needed is to cache it (I assume you > are > > referring to the actual data) in the data provider. How can that be done > > when the size is being called when there is no way to get the current > offset > > that is needed to get the data in the first place? > > > > -----Original Message- > > From: Hoover, William [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 27, 2008 7:55 AM > > To: users@wicket.apache.org > > Subject: RE: DataView size() iterator() call order issue > > > > > > The difference is that in the deletion scenario the state of the data > has > > changed. In the pagination scenario the state of the data has not > changed. > > Why is that so difficult to differentiate? > > > > -Original Message- > > From: Johan Compagner [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 27, 2008 7:49 AM > > To: users@wicket.apache.org > > Subject: Re: DataView size() iterator() call order issue > > > > > > and how do we know the difference? > > > > You as a developer know it, we dont know it as a framework, just cache > it > > in > > your dataprovider or wrap in in a caching data provider. Why is that so > > difficult > > > > johan > > > > > > On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]> > > wrote: > > > > > That makes perfect sense in the scenario where rows are deleted, but > it > > > doesn't make sense when all that is being done is clicking the next > > button > > > for a PagingNavigator. Why would do we need two calls to the size > method > > in > > > that scenario? > > > > > > -Original Message- > > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 26, 2008 3:27 PM > > > To: users@wicket.apache.org > > > Subject: Re: DataView size() iterator() call order issue > > > > > > > > > On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED] > > > > > wrote: > > > > 2) Although AbstractPageableView does ensure the cached item count > is > > > used before calling the data provider size() in getRowCount(), the > > cached > > > item count is "cleared" in onBeforeRender() before the call is made to > > > getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() > > when > > > getting the item models in getItemModels(); This causes an unnecessary > > > duplicate call to the data providers size() method when paginating. > > > > > > it is not unnecessary > > > > > > suppose you h
RE: DataView size() iterator() call order issue
Okay, two issues... (1) combined call for size/data (2) multiple calls to
size() when paginating
I will avoid confusion by addressing only the multiple calls to size() for now.
If only the size was to be cached, as you suggested, how would the data
provider know when to clear it? The data provider is statefull and maintains
the size across requests and there is no "onBeforeRender" in a data provider
like there is in AbstractPageableView. So, the size will never be cleared when
paginating from one page to the next. Even if we were able to cache the size we
would be maintaining the same data in two different locations- in the
AbstractPageableView -> cachedItemCount and in the data provider.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 8:12 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
no cache the size.
We first have to have the size to be able to give you the offset and count
params.
And depending of the type of data or the database you use you could also
already query the data (in the size() call)
But i know that is not always the best thing to do.
But do you want an extra 2 params also in the size() call?
What would be the offset and what would be the max length?
The problem is that both of those depends on the size call.
So the offset is calculated with the size param as is the count..
So if we try to guess those 2 params for the size() call then those 2 params
dont have to be the same for the iterator call...
johan
On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> Also, you mention that all that is needed is to cache it (I assume you are
> referring to the actual data) in the data provider. How can that be done
> when the size is being called when there is no way to get the current offset
> that is needed to get the data in the first place?
>
> -Original Message-
> From: Hoover, William [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2008 7:55 AM
> To: users@wicket.apache.org
> Subject: RE: DataView size() iterator() call order issue
>
>
> The difference is that in the deletion scenario the state of the data has
> changed. In the pagination scenario the state of the data has not changed.
> Why is that so difficult to differentiate?
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2008 7:49 AM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> and how do we know the difference?
>
> You as a developer know it, we dont know it as a framework, just cache it
> in
> your dataprovider or wrap in in a caching data provider. Why is that so
> difficult
>
> johan
>
>
> On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>
> > That makes perfect sense in the scenario where rows are deleted, but it
> > doesn't make sense when all that is being done is clicking the next
> button
> > for a PagingNavigator. Why would do we need two calls to the size method
> in
> > that scenario?
> >
> > -----Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2008 3:27 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> > > 2) Although AbstractPageableView does ensure the cached item count is
> > used before calling the data provider size() in getRowCount(), the
> cached
> > item count is "cleared" in onBeforeRender() before the call is made to
> > getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount()
> when
> > getting the item models in getItemModels(); This causes an unnecessary
> > duplicate call to the data providers size() method when paginating.
> >
> > it is not unnecessary
> >
> > suppose you have a dataview with overridden isvisible() { return
> > getitemcount()>0; }
> > inside this dataview you have a delete link
> >
> > suppose dataview loads and has 1 item.
> > user clicks delete
> > wicket checks the link is indeed visible - which results it the size()
> > call which in turn caches the result
> > onclick() handler is invoked
> > row is removed
> > onbeforerender is called
> > dataview is rendered
> >
> > in this case dataview is rendered because getitemcount() has been
> > cached before onclick() has been executed, so the cached count is 1
> > when in reality there are now 0 items. that is why onbeforerender()
Re: DataView size() iterator() call order issue
no cache the size.
We first have to have the size to be able to give you the offset and count
params.
And depending of the type of data or the database you use you could also
already query the data (in the size() call)
But i know that is not always the best thing to do.
But do you want an extra 2 params also in the size() call?
What would be the offset and what would be the max length?
The problem is that both of those depends on the size call.
So the offset is calculated with the size param as is the count..
So if we try to guess those 2 params for the size() call then those 2 params
dont have to be the same for the iterator call...
johan
On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> Also, you mention that all that is needed is to cache it (I assume you are
> referring to the actual data) in the data provider. How can that be done
> when the size is being called when there is no way to get the current offset
> that is needed to get the data in the first place?
>
> -Original Message-
> From: Hoover, William [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2008 7:55 AM
> To: users@wicket.apache.org
> Subject: RE: DataView size() iterator() call order issue
>
>
> The difference is that in the deletion scenario the state of the data has
> changed. In the pagination scenario the state of the data has not changed.
> Why is that so difficult to differentiate?
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2008 7:49 AM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> and how do we know the difference?
>
> You as a developer know it, we dont know it as a framework, just cache it
> in
> your dataprovider or wrap in in a caching data provider. Why is that so
> difficult
>
> johan
>
>
> On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>
> > That makes perfect sense in the scenario where rows are deleted, but it
> > doesn't make sense when all that is being done is clicking the next
> button
> > for a PagingNavigator. Why would do we need two calls to the size method
> in
> > that scenario?
> >
> > -----Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2008 3:27 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> > > 2) Although AbstractPageableView does ensure the cached item count is
> > used before calling the data provider size() in getRowCount(), the
> cached
> > item count is "cleared" in onBeforeRender() before the call is made to
> > getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount()
> when
> > getting the item models in getItemModels(); This causes an unnecessary
> > duplicate call to the data providers size() method when paginating.
> >
> > it is not unnecessary
> >
> > suppose you have a dataview with overridden isvisible() { return
> > getitemcount()>0; }
> > inside this dataview you have a delete link
> >
> > suppose dataview loads and has 1 item.
> > user clicks delete
> > wicket checks the link is indeed visible - which results it the size()
> > call which in turn caches the result
> > onclick() handler is invoked
> > row is removed
> > onbeforerender is called
> > dataview is rendered
> >
> > in this case dataview is rendered because getitemcount() has been
> > cached before onclick() has been executed, so the cached count is 1
> > when in reality there are now 0 items. that is why onbeforerender()
> > clears the cache, and why sometimes you will get two size() calls.
> >
> > -igor
> >
> > -
> > 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]
> >
> >
>
>
> -
> 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: DataView size() iterator() call order issue
Also, you mention that all that is needed is to cache it (I assume you are
referring to the actual data) in the data provider. How can that be done when
the size is being called when there is no way to get the current offset that is
needed to get the data in the first place?
-Original Message-
From: Hoover, William [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 7:55 AM
To: users@wicket.apache.org
Subject: RE: DataView size() iterator() call order issue
The difference is that in the deletion scenario the state of the data has
changed. In the pagination scenario the state of the data has not changed. Why
is that so difficult to differentiate?
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 7:49 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
and how do we know the difference?
You as a developer know it, we dont know it as a framework, just cache it in
your dataprovider or wrap in in a caching data provider. Why is that so
difficult
johan
On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> That makes perfect sense in the scenario where rows are deleted, but it
> doesn't make sense when all that is being done is clicking the next button
> for a PagingNavigator. Why would do we need two calls to the size method in
> that scenario?
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 3:27 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
> > 2) Although AbstractPageableView does ensure the cached item count is
> used before calling the data provider size() in getRowCount(), the cached
> item count is "cleared" in onBeforeRender() before the call is made to
> getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() when
> getting the item models in getItemModels(); This causes an unnecessary
> duplicate call to the data providers size() method when paginating.
>
> it is not unnecessary
>
> suppose you have a dataview with overridden isvisible() { return
> getitemcount()>0; }
> inside this dataview you have a delete link
>
> suppose dataview loads and has 1 item.
> user clicks delete
> wicket checks the link is indeed visible - which results it the size()
> call which in turn caches the result
> onclick() handler is invoked
> row is removed
> onbeforerender is called
> dataview is rendered
>
> in this case dataview is rendered because getitemcount() has been
> cached before onclick() has been executed, so the cached count is 1
> when in reality there are now 0 items. that is why onbeforerender()
> clears the cache, and why sometimes you will get two size() calls.
>
> -igor
>
> -
> 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]
>
>
-
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: DataView size() iterator() call order issue
The difference is that in the deletion scenario the state of the data has
changed. In the pagination scenario the state of the data has not changed. Why
is that so difficult to differentiate?
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 7:49 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
and how do we know the difference?
You as a developer know it, we dont know it as a framework, just cache it in
your dataprovider or wrap in in a caching data provider. Why is that so
difficult
johan
On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> That makes perfect sense in the scenario where rows are deleted, but it
> doesn't make sense when all that is being done is clicking the next button
> for a PagingNavigator. Why would do we need two calls to the size method in
> that scenario?
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 3:27 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
> > 2) Although AbstractPageableView does ensure the cached item count is
> used before calling the data provider size() in getRowCount(), the cached
> item count is "cleared" in onBeforeRender() before the call is made to
> getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() when
> getting the item models in getItemModels(); This causes an unnecessary
> duplicate call to the data providers size() method when paginating.
>
> it is not unnecessary
>
> suppose you have a dataview with overridden isvisible() { return
> getitemcount()>0; }
> inside this dataview you have a delete link
>
> suppose dataview loads and has 1 item.
> user clicks delete
> wicket checks the link is indeed visible - which results it the size()
> call which in turn caches the result
> onclick() handler is invoked
> row is removed
> onbeforerender is called
> dataview is rendered
>
> in this case dataview is rendered because getitemcount() has been
> cached before onclick() has been executed, so the cached count is 1
> when in reality there are now 0 items. that is why onbeforerender()
> clears the cache, and why sometimes you will get two size() calls.
>
> -igor
>
> -
> 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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DataView size() iterator() call order issue
and how do we know the difference?
You as a developer know it, we dont know it as a framework, just cache it in
your dataprovider or wrap in in a caching data provider. Why is that so
difficult
johan
On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> That makes perfect sense in the scenario where rows are deleted, but it
> doesn't make sense when all that is being done is clicking the next button
> for a PagingNavigator. Why would do we need two calls to the size method in
> that scenario?
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 3:27 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
> > 2) Although AbstractPageableView does ensure the cached item count is
> used before calling the data provider size() in getRowCount(), the cached
> item count is "cleared" in onBeforeRender() before the call is made to
> getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() when
> getting the item models in getItemModels(); This causes an unnecessary
> duplicate call to the data providers size() method when paginating.
>
> it is not unnecessary
>
> suppose you have a dataview with overridden isvisible() { return
> getitemcount()>0; }
> inside this dataview you have a delete link
>
> suppose dataview loads and has 1 item.
> user clicks delete
> wicket checks the link is indeed visible - which results it the size()
> call which in turn caches the result
> onclick() handler is invoked
> row is removed
> onbeforerender is called
> dataview is rendered
>
> in this case dataview is rendered because getitemcount() has been
> cached before onclick() has been executed, so the cached count is 1
> when in reality there are now 0 items. that is why onbeforerender()
> clears the cache, and why sometimes you will get two size() calls.
>
> -igor
>
> -
> 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: DataView size() iterator() call order issue
How can the offset in the AbstractPageableView -> getViewOffset() be accessed
in a IDataProvider? Does the proposed solution make sense?
-Original Message-
From: Hoover, William [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 2:39 PM
To: users@wicket.apache.org
Subject: RE: DataView size() iterator() call order issue
If we are caching the data as well as the size then we get that from the cache.
The call that gets data/size can check the cache. If it is not cached then make
the query call to get it.
public final int size() {
if (getItemCountCache() > 0 || getDataCache() == null) {
search(getOffsetCache(), getItemsPerPageCache()); //
query size/data and set the cache
}
return getItemCountCache();
}
// change: "public final Iterator iterator(final int first,
final int count) {" to:
public final Iterator iterator() {
if (getItemCountCache() > 0 || getDataCache() == null) {
search(getOffsetCache(), getItemsPerPageCache()); //
query size/data and set the cache
}
return getDataCache();
}
If someone is concerned with retrieving the size before making the expensive
call to get the data they can make two separate calls, one to query/set the
size cache, and another to query/set the data cache (if the size is > 0).
Personally, I would prefer to let that be determined by the business tier via a
BPM system.
There are 2 outstanding issues:
1) There should be a means to access the offset cache, items per page cache,
and a data cache. All of which can get cleared when the fix for issue 2 is
resolved ;o)
2) Although AbstractPageableView does ensure the cached item count is used
before calling the data provider size() in getRowCount(), the cached item count
is "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
models in getItemModels(); This causes an unnecessary duplicate call to the
data providers size() method when paginating.
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 1:32 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
we are getting off track though.
suppose class result { int size; iterator data } and idataprovider {
result getdata(int first, int count); }
how do we handle usecases where we just need the size and dont know
first/count yet?
-igor
On Wed, Mar 26, 2008 at 7:19 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> see below...
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>
> Sent: Monday, March 24, 2008 5:13 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
>
> how are we going to cover these usecases:
>
> * pagination toolbar needs to call dataprovier.size() to figure out
> how many total records there are. at this point the toolbar doesnt
> know what window of data to retrieve, it just wants to know the size.
> [Will]: Currently, the size() method is called twice when paginating using
> PagingNavigator (not to mention the call for isvisible you describe below).
> This causes issues with duplicate query calls if the count is queried in the
> size() method. Could there be transient properties in the data provider that
> cache the count/list of items that would be cleared when rendered? If that
> were the case there could be an abstract method defined in the data provider
> interface to query/set the results.
>
>
> * often users do:
> new dataview() { isvisible() { return dataprovider.size()>0; }
> once again, datawindow size is not known.
> [Will]: This would be accommodated by the above solution.
>
>
>
> -igor
>
>
>
> On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> > We are using a modified version of the Generic DAO for Hibernate
> (http://www.hibernate.org/328.html) where we make reuse of common DAO methods
> such as keyword searches that retrieve corresponding entities as well a total
> size (both use the same search criteria when determining results so it makes
> sense to combine the operations). As you stated, we are making two calls the
> database, but only one call to the DAO (although, as stated in previous
> responses there are alternative ways to perform one query to achieve this).
> >
> > Our business tier handles the transactions for us (not our DAOs ;o) using
> an event model (similar to typical BPM systems). Broadcast agents are used to
> notify our business listeners which in turn process our DAO calls. This gi
RE: DataView size() iterator() call order issue
That makes perfect sense in the scenario where rows are deleted, but it doesn't
make sense when all that is being done is clicking the next button for a
PagingNavigator. Why would do we need two calls to the size method in that
scenario?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 3:27 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> 2) Although AbstractPageableView does ensure the cached item count is used
> before calling the data provider size() in getRowCount(), the cached item
> count is "cleared" in onBeforeRender() before the call is made to
> getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() when
> getting the item models in getItemModels(); This causes an unnecessary
> duplicate call to the data providers size() method when paginating.
it is not unnecessary
suppose you have a dataview with overridden isvisible() { return
getitemcount()>0; }
inside this dataview you have a delete link
suppose dataview loads and has 1 item.
user clicks delete
wicket checks the link is indeed visible - which results it the size()
call which in turn caches the result
onclick() handler is invoked
row is removed
onbeforerender is called
dataview is rendered
in this case dataview is rendered because getitemcount() has been
cached before onclick() has been executed, so the cached count is 1
when in reality there are now 0 items. that is why onbeforerender()
clears the cache, and why sometimes you will get two size() calls.
-igor
-
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: DataView size() iterator() call order issue
On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> 2) Although AbstractPageableView does ensure the cached item count is used
> before calling the data provider size() in getRowCount(), the cached item
> count is "cleared" in onBeforeRender() before the call is made to
> getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() when
> getting the item models in getItemModels(); This causes an unnecessary
> duplicate call to the data providers size() method when paginating.
it is not unnecessary
suppose you have a dataview with overridden isvisible() { return
getitemcount()>0; }
inside this dataview you have a delete link
suppose dataview loads and has 1 item.
user clicks delete
wicket checks the link is indeed visible - which results it the size()
call which in turn caches the result
onclick() handler is invoked
row is removed
onbeforerender is called
dataview is rendered
in this case dataview is rendered because getitemcount() has been
cached before onclick() has been executed, so the cached count is 1
when in reality there are now 0 items. that is why onbeforerender()
clears the cache, and why sometimes you will get two size() calls.
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: DataView size() iterator() call order issue
If we are caching the data as well as the size then we get that from the cache.
The call that gets data/size can check the cache. If it is not cached then make
the query call to get it.
public final int size() {
if (getItemCountCache() > 0 || getDataCache() == null) {
search(getOffsetCache(), getItemsPerPageCache()); //
query size/data and set the cache
}
return getItemCountCache();
}
// change: "public final Iterator iterator(final int first,
final int count) {" to:
public final Iterator iterator() {
if (getItemCountCache() > 0 || getDataCache() == null) {
search(getOffsetCache(), getItemsPerPageCache()); //
query size/data and set the cache
}
return getDataCache();
}
If someone is concerned with retrieving the size before making the expensive
call to get the data they can make two separate calls, one to query/set the
size cache, and another to query/set the data cache (if the size is > 0).
Personally, I would prefer to let that be determined by the business tier via a
BPM system.
There are 2 outstanding issues:
1) There should be a means to access the offset cache, items per page cache,
and a data cache. All of which can get cleared when the fix for issue 2 is
resolved ;o)
2) Although AbstractPageableView does ensure the cached item count is used
before calling the data provider size() in getRowCount(), the cached item count
is "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
models in getItemModels(); This causes an unnecessary duplicate call to the
data providers size() method when paginating.
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 1:32 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
we are getting off track though.
suppose class result { int size; iterator data } and idataprovider {
result getdata(int first, int count); }
how do we handle usecases where we just need the size and dont know
first/count yet?
-igor
On Wed, Mar 26, 2008 at 7:19 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> see below...
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>
> Sent: Monday, March 24, 2008 5:13 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
>
> how are we going to cover these usecases:
>
> * pagination toolbar needs to call dataprovier.size() to figure out
> how many total records there are. at this point the toolbar doesnt
> know what window of data to retrieve, it just wants to know the size.
> [Will]: Currently, the size() method is called twice when paginating using
> PagingNavigator (not to mention the call for isvisible you describe below).
> This causes issues with duplicate query calls if the count is queried in the
> size() method. Could there be transient properties in the data provider that
> cache the count/list of items that would be cleared when rendered? If that
> were the case there could be an abstract method defined in the data provider
> interface to query/set the results.
>
>
> * often users do:
> new dataview() { isvisible() { return dataprovider.size()>0; }
> once again, datawindow size is not known.
> [Will]: This would be accommodated by the above solution.
>
>
>
> -igor
>
>
>
> On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> > We are using a modified version of the Generic DAO for Hibernate
> (http://www.hibernate.org/328.html) where we make reuse of common DAO methods
> such as keyword searches that retrieve corresponding entities as well a total
> size (both use the same search criteria when determining results so it makes
> sense to combine the operations). As you stated, we are making two calls the
> database, but only one call to the DAO (although, as stated in previous
> responses there are alternative ways to perform one query to achieve this).
> >
> > Our business tier handles the transactions for us (not our DAOs ;o) using
> an event model (similar to typical BPM systems). Broadcast agents are used to
> notify our business listeners which in turn process our DAO calls. This gives
> us an the flexibility to have independent transactions for different business
> rule operations and makes the most out of code reuse.
> >
> > Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the oper
RE: DataView size() iterator() call order issue
If we are caching the data as well as the size then we get that from the cache.
The call that gets data/size can check the cache. If it is not cached then make
the query call to get it.
public final int size() {
if (getItemCountCache() > 0 || getDataCache() == null) {
search(getOffsetCache(), getItemsPerPageCache()); //
query size/data
}
return getItemCountCache();
}
// change: "public final Iterator iterator(final int first,
final int count) {" to:
public final Iterator iterator() {
if (getItemCountCache() > 0 || getDataCache() == null) {
search(getOffsetCache(), getItemsPerPageCache()); //
query size/data
}
return getDataCache();
}
If someone is concerned with retrieving the size before making the expensive
call to get the data they can make two separate calls, one to query/set the
size cache, and another to query/set the data cache (if the size is > 0).
Personally, I would prefer to let that be determined by the business tier via a
BPM system.
There are 2 outstanding issues:
1) There should be a means to access the offset cache, items per page cache,
and a data cache. All of which can get cleared when the fix for issue 2 is
resolved ;o)
2) Although AbstractPageableView does ensure the cached item count is used
before calling the data provider size() in getRowCount(), the cached item count
is "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
models in getItemModels(); This causes an unnecessary duplicate call to the
data providers size() method when paginating.
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 1:32 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
we are getting off track though.
suppose class result { int size; iterator data } and idataprovider {
result getdata(int first, int count); }
how do we handle usecases where we just need the size and dont know
first/count yet?
-igor
On Wed, Mar 26, 2008 at 7:19 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> see below...
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>
> Sent: Monday, March 24, 2008 5:13 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
>
> how are we going to cover these usecases:
>
> * pagination toolbar needs to call dataprovier.size() to figure out
> how many total records there are. at this point the toolbar doesnt
> know what window of data to retrieve, it just wants to know the size.
> [Will]: Currently, the size() method is called twice when paginating using
> PagingNavigator (not to mention the call for isvisible you describe below).
> This causes issues with duplicate query calls if the count is queried in the
> size() method. Could there be transient properties in the data provider that
> cache the count/list of items that would be cleared when rendered? If that
> were the case there could be an abstract method defined in the data provider
> interface to query/set the results.
>
>
> * often users do:
> new dataview() { isvisible() { return dataprovider.size()>0; }
> once again, datawindow size is not known.
> [Will]: This would be accommodated by the above solution.
>
>
>
> -igor
>
>
>
> On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> > We are using a modified version of the Generic DAO for Hibernate
> (http://www.hibernate.org/328.html) where we make reuse of common DAO methods
> such as keyword searches that retrieve corresponding entities as well a total
> size (both use the same search criteria when determining results so it makes
> sense to combine the operations). As you stated, we are making two calls the
> database, but only one call to the DAO (although, as stated in previous
> responses there are alternative ways to perform one query to achieve this).
> >
> > Our business tier handles the transactions for us (not our DAOs ;o) using
> an event model (similar to typical BPM systems). Broadcast agents are used to
> notify our business listeners which in turn process our DAO calls. This gives
> us an the flexibility to have independent transactions for different business
> rule operations and makes the most out of code reuse.
> >
> > Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the operation were combined so that the i
RE: DataView size() iterator() call order issue
The size is cached in AbstractPageableView via getRowCount() ->
setCachedItemCount(count), but how does the data provider access it without
making a reference to the pageable view? Also, seeing that it is getting
cached, why is size() getting called twice when paginating using
PagingNavigator? Couldn't it use the cached item count?
The framework doesn't have to know if it always returns the same. It is set by
the implementer when it returns the count() in the data provider and when it
sets the validated cached count in the AbstractPageableView.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 12:34 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
dont know if we really can do that
I dont know if the size() call really always in the same request returns the
same..
You as a developer can know that but we as a framework, dont know about
that.
I thought the size was already cached in specific places
But you can easily make a wrapper ofcourse..
CachingDataProvider implements IDataProvider
{
IDataProvider delegate;
}
johan
On Wed, Mar 26, 2008 at 5:24 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> What I was referring to as default behavior is a possible abstraction
> class for the data provider so that implementers would not have to deal with
> duplicate calls to the size() (and dealing with checking if the size has
> been queried already in the same request).
>
> The issue still remains even with the cache because the first and count is
> needed in order to make the combined call that retrieves the results/count.
> What is needed is a way to extract first when the size() method is called
> (and possibly a means to pass the queried count to validate it and return
> the validated value- like it does now). Is there currently a way to do that?
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 12:12 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> default behavior?
> what do you mean?
> IDataprovider is an interface, how can this have default behavior
>
> You can cache your results if you want
> So if you want in the size() call you can do anything you want, for
> example
> getting already the data.
> If that is not possible then yes you have to wait for that to the iterator
> call
> But still size can be reused across the request.
>
> johan
>
>
> On Wed, Mar 26, 2008 at 4:32 PM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>
> > Wouldn't it be more flexible if this were the default behavior? The
> size()
> > method is called (sometimes multiple times- such is the case with
> pagination
> > or the check igor described) before the iterator(first, count) method.
> We
> > use only one call to our DAOs to retrieve both the results and the
> count.
> > The problem is that the first and count are unknown until the iterator
> > method is called.
> >
> > -----Original Message-
> > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2008 10:54 AM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > yes you can cache those values
> > IDataProvider does extends IDetachable
> > and in detach() you can clear those values.
> >
> >
> > On Wed, Mar 26, 2008 at 3:19 PM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> >
> > > see below...
> > >
> > > -Original Message-
> > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, March 24, 2008 5:13 PM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > how are we going to cover these usecases:
> > >
> > > * pagination toolbar needs to call dataprovier.size() to figure out
> > > how many total records there are. at this point the toolbar doesnt
> > > know what window of data to retrieve, it just wants to know the size.
> > > [Will]: Currently, the size() method is called twice when paginating
> > using
> > > PagingNavigator (not to mention the call for isvisible you describe
> > below).
> > > This causes issues with duplicate query calls if the count is queried
> in
> > the
> > > size() method. Could there be transient properties in the data
> provider
> > that
> > > cache the count/list of items that would be cleared when rendered? If
> > that
> > > were the case there could be an abstrac
Re: DataView size() iterator() call order issue
we are getting off track though.
suppose class result { int size; iterator data } and idataprovider {
result getdata(int first, int count); }
how do we handle usecases where we just need the size and dont know
first/count yet?
-igor
On Wed, Mar 26, 2008 at 7:19 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> see below...
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>
> Sent: Monday, March 24, 2008 5:13 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
>
> how are we going to cover these usecases:
>
> * pagination toolbar needs to call dataprovier.size() to figure out
> how many total records there are. at this point the toolbar doesnt
> know what window of data to retrieve, it just wants to know the size.
> [Will]: Currently, the size() method is called twice when paginating using
> PagingNavigator (not to mention the call for isvisible you describe below).
> This causes issues with duplicate query calls if the count is queried in the
> size() method. Could there be transient properties in the data provider that
> cache the count/list of items that would be cleared when rendered? If that
> were the case there could be an abstract method defined in the data provider
> interface to query/set the results.
>
>
> * often users do:
> new dataview() { isvisible() { return dataprovider.size()>0; }
> once again, datawindow size is not known.
> [Will]: This would be accommodated by the above solution.
>
>
>
> -igor
>
>
>
> On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> > We are using a modified version of the Generic DAO for Hibernate
> (http://www.hibernate.org/328.html) where we make reuse of common DAO methods
> such as keyword searches that retrieve corresponding entities as well a total
> size (both use the same search criteria when determining results so it makes
> sense to combine the operations). As you stated, we are making two calls the
> database, but only one call to the DAO (although, as stated in previous
> responses there are alternative ways to perform one query to achieve this).
> >
> > Our business tier handles the transactions for us (not our DAOs ;o) using
> an event model (similar to typical BPM systems). Broadcast agents are used to
> notify our business listeners which in turn process our DAO calls. This gives
> us an the flexibility to have independent transactions for different business
> rule operations and makes the most out of code reuse.
> >
> > Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the operation were combined so that the implementation could
> determine how/when to make the call to the persistence tier for the two
> operations. I guess I'm not seeing why we need the count before the iterator.
> The data provider impl can determine whether or not it will make the
> expensive call for the results.
> >
> >
> > -Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> >
> > Sent: Friday, March 21, 2008 2:44 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> >
> >
> > knowing the size and the window together seems like a ui requirement,
> > it is a bit strange to me that you have it inside a dao which should
> > cater to business logic. eg, as far as i know there is no single db
> > operation that will produce both, so you are still doing two calls
> > inside the dao.
> >
> > also transaction management should be handled outside the dao, daos
> > are too fine an object to implement transaction management for.
> >
> > anywho, just nitpicking :)
> >
> > size() is called first for a lot of reasons, namely even knowing if
> > there are any rows to retrieve before a much heavier iterator() is
> > called. some clients want to hide a repeater if there are no items
> > visible, and so size() might get called from inside isvisible() as
> > well.
> >
> > idataprovider is quiet old and we havent had many complaints about its
> > design so far. if all you are using is the dataview it should be
> > pretty simple for you to roll your own dataview, if you look at
> > dataview all it does is implement idataprovider handling to feed the
> > pageable view. however, if you do you will also lose datatable as well
> > :|
> >
> > if you got suggestions on how to improve it
Re: DataView size() iterator() call order issue
dont know if we really can do that
I dont know if the size() call really always in the same request returns the
same..
You as a developer can know that but we as a framework, dont know about
that.
I thought the size was already cached in specific places
But you can easily make a wrapper ofcourse..
CachingDataProvider implements IDataProvider
{
IDataProvider delegate;
}
johan
On Wed, Mar 26, 2008 at 5:24 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> What I was referring to as default behavior is a possible abstraction
> class for the data provider so that implementers would not have to deal with
> duplicate calls to the size() (and dealing with checking if the size has
> been queried already in the same request).
>
> The issue still remains even with the cache because the first and count is
> needed in order to make the combined call that retrieves the results/count.
> What is needed is a way to extract first when the size() method is called
> (and possibly a means to pass the queried count to validate it and return
> the validated value- like it does now). Is there currently a way to do that?
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 12:12 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> default behavior?
> what do you mean?
> IDataprovider is an interface, how can this have default behavior
>
> You can cache your results if you want
> So if you want in the size() call you can do anything you want, for
> example
> getting already the data.
> If that is not possible then yes you have to wait for that to the iterator
> call
> But still size can be reused across the request.
>
> johan
>
>
> On Wed, Mar 26, 2008 at 4:32 PM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>
> > Wouldn't it be more flexible if this were the default behavior? The
> size()
> > method is called (sometimes multiple times- such is the case with
> pagination
> > or the check igor described) before the iterator(first, count) method.
> We
> > use only one call to our DAOs to retrieve both the results and the
> count.
> > The problem is that the first and count are unknown until the iterator
> > method is called.
> >
> > -----Original Message-
> > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2008 10:54 AM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > yes you can cache those values
> > IDataProvider does extends IDetachable
> > and in detach() you can clear those values.
> >
> >
> > On Wed, Mar 26, 2008 at 3:19 PM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> >
> > > see below...
> > >
> > > -Original Message-
> > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, March 24, 2008 5:13 PM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > how are we going to cover these usecases:
> > >
> > > * pagination toolbar needs to call dataprovier.size() to figure out
> > > how many total records there are. at this point the toolbar doesnt
> > > know what window of data to retrieve, it just wants to know the size.
> > > [Will]: Currently, the size() method is called twice when paginating
> > using
> > > PagingNavigator (not to mention the call for isvisible you describe
> > below).
> > > This causes issues with duplicate query calls if the count is queried
> in
> > the
> > > size() method. Could there be transient properties in the data
> provider
> > that
> > > cache the count/list of items that would be cleared when rendered? If
> > that
> > > were the case there could be an abstract method defined in the data
> > provider
> > > interface to query/set the results.
> > >
> > > * often users do:
> > > new dataview() { isvisible() { return dataprovider.size()>0; }
> > > once again, datawindow size is not known.
> > > [Will]: This would be accommodated by the above solution.
> > >
> > > -igor
> > >
> > >
> > >
> > > On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]>
> > > wrote:
> > > > We are using a modified version of the Generic DAO for Hibernate (
> > > http://www.hibernate.org/328.html) where we make reuse of common DAO
> > > methods such as keyword searches that
RE: DataView size() iterator() call order issue
What I was referring to as default behavior is a possible abstraction class for
the data provider so that implementers would not have to deal with duplicate
calls to the size() (and dealing with checking if the size has been queried
already in the same request).
The issue still remains even with the cache because the first and count is
needed in order to make the combined call that retrieves the results/count.
What is needed is a way to extract first when the size() method is called (and
possibly a means to pass the queried count to validate it and return the
validated value- like it does now). Is there currently a way to do that?
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 12:12 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
default behavior?
what do you mean?
IDataprovider is an interface, how can this have default behavior
You can cache your results if you want
So if you want in the size() call you can do anything you want, for example
getting already the data.
If that is not possible then yes you have to wait for that to the iterator
call
But still size can be reused across the request.
johan
On Wed, Mar 26, 2008 at 4:32 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> Wouldn't it be more flexible if this were the default behavior? The size()
> method is called (sometimes multiple times- such is the case with pagination
> or the check igor described) before the iterator(first, count) method. We
> use only one call to our DAOs to retrieve both the results and the count.
> The problem is that the first and count are unknown until the iterator
> method is called.
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 10:54 AM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> yes you can cache those values
> IDataProvider does extends IDetachable
> and in detach() you can clear those values.
>
>
> On Wed, Mar 26, 2008 at 3:19 PM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>
> > see below...
> >
> > -Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > Sent: Monday, March 24, 2008 5:13 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > how are we going to cover these usecases:
> >
> > * pagination toolbar needs to call dataprovier.size() to figure out
> > how many total records there are. at this point the toolbar doesnt
> > know what window of data to retrieve, it just wants to know the size.
> > [Will]: Currently, the size() method is called twice when paginating
> using
> > PagingNavigator (not to mention the call for isvisible you describe
> below).
> > This causes issues with duplicate query calls if the count is queried in
> the
> > size() method. Could there be transient properties in the data provider
> that
> > cache the count/list of items that would be cleared when rendered? If
> that
> > were the case there could be an abstract method defined in the data
> provider
> > interface to query/set the results.
> >
> > * often users do:
> > new dataview() { isvisible() { return dataprovider.size()>0; }
> > once again, datawindow size is not known.
> > [Will]: This would be accommodated by the above solution.
> >
> > -igor
> >
> >
> >
> > On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> > > We are using a modified version of the Generic DAO for Hibernate (
> > http://www.hibernate.org/328.html) where we make reuse of common DAO
> > methods such as keyword searches that retrieve corresponding entities as
> > well a total size (both use the same search criteria when determining
> > results so it makes sense to combine the operations). As you stated, we
> are
> > making two calls the database, but only one call to the DAO (although,
> as
> > stated in previous responses there are alternative ways to perform one
> query
> > to achieve this).
> > >
> > > Our business tier handles the transactions for us (not our DAOs ;o)
> > using an event model (similar to typical BPM systems). Broadcast agents
> are
> > used to notify our business listeners which in turn process our DAO
> calls.
> > This gives us an the flexibility to have independent transactions for
> > different business rule operations and makes the most out of code reuse.
> > >
> > > Avoiding the heavier call makes perfect sense, but couldn't this
> > responsibility be pas
Re: DataView size() iterator() call order issue
default behavior?
what do you mean?
IDataprovider is an interface, how can this have default behavior
You can cache your results if you want
So if you want in the size() call you can do anything you want, for example
getting already the data.
If that is not possible then yes you have to wait for that to the iterator
call
But still size can be reused across the request.
johan
On Wed, Mar 26, 2008 at 4:32 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> Wouldn't it be more flexible if this were the default behavior? The size()
> method is called (sometimes multiple times- such is the case with pagination
> or the check igor described) before the iterator(first, count) method. We
> use only one call to our DAOs to retrieve both the results and the count.
> The problem is that the first and count are unknown until the iterator
> method is called.
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 10:54 AM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> yes you can cache those values
> IDataProvider does extends IDetachable
> and in detach() you can clear those values.
>
>
> On Wed, Mar 26, 2008 at 3:19 PM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
>
> > see below...
> >
> > -Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > Sent: Monday, March 24, 2008 5:13 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > how are we going to cover these usecases:
> >
> > * pagination toolbar needs to call dataprovier.size() to figure out
> > how many total records there are. at this point the toolbar doesnt
> > know what window of data to retrieve, it just wants to know the size.
> > [Will]: Currently, the size() method is called twice when paginating
> using
> > PagingNavigator (not to mention the call for isvisible you describe
> below).
> > This causes issues with duplicate query calls if the count is queried in
> the
> > size() method. Could there be transient properties in the data provider
> that
> > cache the count/list of items that would be cleared when rendered? If
> that
> > were the case there could be an abstract method defined in the data
> provider
> > interface to query/set the results.
> >
> > * often users do:
> > new dataview() { isvisible() { return dataprovider.size()>0; }
> > once again, datawindow size is not known.
> > [Will]: This would be accommodated by the above solution.
> >
> > -igor
> >
> >
> >
> > On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> > > We are using a modified version of the Generic DAO for Hibernate (
> > http://www.hibernate.org/328.html) where we make reuse of common DAO
> > methods such as keyword searches that retrieve corresponding entities as
> > well a total size (both use the same search criteria when determining
> > results so it makes sense to combine the operations). As you stated, we
> are
> > making two calls the database, but only one call to the DAO (although,
> as
> > stated in previous responses there are alternative ways to perform one
> query
> > to achieve this).
> > >
> > > Our business tier handles the transactions for us (not our DAOs ;o)
> > using an event model (similar to typical BPM systems). Broadcast agents
> are
> > used to notify our business listeners which in turn process our DAO
> calls.
> > This gives us an the flexibility to have independent transactions for
> > different business rule operations and makes the most out of code reuse.
> > >
> > > Avoiding the heavier call makes perfect sense, but couldn't this
> > responsibility be passed to the data provider implementation? It may
> make
> > more sense if the operation were combined so that the implementation
> could
> > determine how/when to make the call to the persistence tier for the two
> > operations. I guess I'm not seeing why we need the count before the
> > iterator. The data provider impl can determine whether or not it will
> make
> > the expensive call for the results.
> > >
> > >
> > > -Original Message-
> > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > >
> > > Sent: Friday, March 21, 2008 2:44 PM
> > > To: users@wicket.apache.org
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > >
> > >
> > > knowing th
RE: DataView size() iterator() call order issue
Wouldn't it be more flexible if this were the default behavior? The size()
method is called (sometimes multiple times- such is the case with pagination or
the check igor described) before the iterator(first, count) method. We use only
one call to our DAOs to retrieve both the results and the count. The problem is
that the first and count are unknown until the iterator method is called.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 10:54 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
yes you can cache those values
IDataProvider does extends IDetachable
and in detach() you can clear those values.
On Wed, Mar 26, 2008 at 3:19 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> see below...
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 24, 2008 5:13 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> how are we going to cover these usecases:
>
> * pagination toolbar needs to call dataprovier.size() to figure out
> how many total records there are. at this point the toolbar doesnt
> know what window of data to retrieve, it just wants to know the size.
> [Will]: Currently, the size() method is called twice when paginating using
> PagingNavigator (not to mention the call for isvisible you describe below).
> This causes issues with duplicate query calls if the count is queried in the
> size() method. Could there be transient properties in the data provider that
> cache the count/list of items that would be cleared when rendered? If that
> were the case there could be an abstract method defined in the data provider
> interface to query/set the results.
>
> * often users do:
> new dataview() { isvisible() { return dataprovider.size()>0; }
> once again, datawindow size is not known.
> [Will]: This would be accommodated by the above solution.
>
> -igor
>
>
>
> On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
> > We are using a modified version of the Generic DAO for Hibernate (
> http://www.hibernate.org/328.html) where we make reuse of common DAO
> methods such as keyword searches that retrieve corresponding entities as
> well a total size (both use the same search criteria when determining
> results so it makes sense to combine the operations). As you stated, we are
> making two calls the database, but only one call to the DAO (although, as
> stated in previous responses there are alternative ways to perform one query
> to achieve this).
> >
> > Our business tier handles the transactions for us (not our DAOs ;o)
> using an event model (similar to typical BPM systems). Broadcast agents are
> used to notify our business listeners which in turn process our DAO calls.
> This gives us an the flexibility to have independent transactions for
> different business rule operations and makes the most out of code reuse.
> >
> > Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the operation were combined so that the implementation could
> determine how/when to make the call to the persistence tier for the two
> operations. I guess I'm not seeing why we need the count before the
> iterator. The data provider impl can determine whether or not it will make
> the expensive call for the results.
> >
> >
> > -Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> >
> > Sent: Friday, March 21, 2008 2:44 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> >
> >
> > knowing the size and the window together seems like a ui requirement,
> > it is a bit strange to me that you have it inside a dao which should
> > cater to business logic. eg, as far as i know there is no single db
> > operation that will produce both, so you are still doing two calls
> > inside the dao.
> >
> > also transaction management should be handled outside the dao, daos
> > are too fine an object to implement transaction management for.
> >
> > anywho, just nitpicking :)
> >
> > size() is called first for a lot of reasons, namely even knowing if
> > there are any rows to retrieve before a much heavier iterator() is
> > called. some clients want to hide a repeater if there are no items
> > visible, and so size() might get called from inside isvisible() as
> > well.
> >
> > idataprovider is quiet old and we havent had many complaints about its
> &g
Re: DataView size() iterator() call order issue
yes you can cache those values
IDataProvider does extends IDetachable
and in detach() you can clear those values.
On Wed, Mar 26, 2008 at 3:19 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:
> see below...
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 24, 2008 5:13 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
> how are we going to cover these usecases:
>
> * pagination toolbar needs to call dataprovier.size() to figure out
> how many total records there are. at this point the toolbar doesnt
> know what window of data to retrieve, it just wants to know the size.
> [Will]: Currently, the size() method is called twice when paginating using
> PagingNavigator (not to mention the call for isvisible you describe below).
> This causes issues with duplicate query calls if the count is queried in the
> size() method. Could there be transient properties in the data provider that
> cache the count/list of items that would be cleared when rendered? If that
> were the case there could be an abstract method defined in the data provider
> interface to query/set the results.
>
> * often users do:
> new dataview() { isvisible() { return dataprovider.size()>0; }
> once again, datawindow size is not known.
> [Will]: This would be accommodated by the above solution.
>
> -igor
>
>
>
> On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
> > We are using a modified version of the Generic DAO for Hibernate (
> http://www.hibernate.org/328.html) where we make reuse of common DAO
> methods such as keyword searches that retrieve corresponding entities as
> well a total size (both use the same search criteria when determining
> results so it makes sense to combine the operations). As you stated, we are
> making two calls the database, but only one call to the DAO (although, as
> stated in previous responses there are alternative ways to perform one query
> to achieve this).
> >
> > Our business tier handles the transactions for us (not our DAOs ;o)
> using an event model (similar to typical BPM systems). Broadcast agents are
> used to notify our business listeners which in turn process our DAO calls.
> This gives us an the flexibility to have independent transactions for
> different business rule operations and makes the most out of code reuse.
> >
> > Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the operation were combined so that the implementation could
> determine how/when to make the call to the persistence tier for the two
> operations. I guess I'm not seeing why we need the count before the
> iterator. The data provider impl can determine whether or not it will make
> the expensive call for the results.
> >
> >
> > -Original Message-
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> >
> > Sent: Friday, March 21, 2008 2:44 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> >
> >
> > knowing the size and the window together seems like a ui requirement,
> > it is a bit strange to me that you have it inside a dao which should
> > cater to business logic. eg, as far as i know there is no single db
> > operation that will produce both, so you are still doing two calls
> > inside the dao.
> >
> > also transaction management should be handled outside the dao, daos
> > are too fine an object to implement transaction management for.
> >
> > anywho, just nitpicking :)
> >
> > size() is called first for a lot of reasons, namely even knowing if
> > there are any rows to retrieve before a much heavier iterator() is
> > called. some clients want to hide a repeater if there are no items
> > visible, and so size() might get called from inside isvisible() as
> > well.
> >
> > idataprovider is quiet old and we havent had many complaints about its
> > design so far. if all you are using is the dataview it should be
> > pretty simple for you to roll your own dataview, if you look at
> > dataview all it does is implement idataprovider handling to feed the
> > pageable view. however, if you do you will also lose datatable as well
> > :|
> >
> > if you got suggestions on how to improve it im all ears.
> >
> > -igor
> >
> >
> > On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
> > > When using DataView/IDataProvider size()
RE: DataView size() iterator() call order issue
see below...
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 5:13 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
how are we going to cover these usecases:
* pagination toolbar needs to call dataprovier.size() to figure out
how many total records there are. at this point the toolbar doesnt
know what window of data to retrieve, it just wants to know the size.
[Will]: Currently, the size() method is called twice when paginating using
PagingNavigator (not to mention the call for isvisible you describe below).
This causes issues with duplicate query calls if the count is queried in the
size() method. Could there be transient properties in the data provider that
cache the count/list of items that would be cleared when rendered? If that were
the case there could be an abstract method defined in the data provider
interface to query/set the results.
* often users do:
new dataview() { isvisible() { return dataprovider.size()>0; }
once again, datawindow size is not known.
[Will]: This would be accommodated by the above solution.
-igor
On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> We are using a modified version of the Generic DAO for Hibernate
> (http://www.hibernate.org/328.html) where we make reuse of common DAO methods
> such as keyword searches that retrieve corresponding entities as well a total
> size (both use the same search criteria when determining results so it makes
> sense to combine the operations). As you stated, we are making two calls the
> database, but only one call to the DAO (although, as stated in previous
> responses there are alternative ways to perform one query to achieve this).
>
> Our business tier handles the transactions for us (not our DAOs ;o) using an
> event model (similar to typical BPM systems). Broadcast agents are used to
> notify our business listeners which in turn process our DAO calls. This gives
> us an the flexibility to have independent transactions for different business
> rule operations and makes the most out of code reuse.
>
> Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the operation were combined so that the implementation could
> determine how/when to make the call to the persistence tier for the two
> operations. I guess I'm not seeing why we need the count before the iterator.
> The data provider impl can determine whether or not it will make the
> expensive call for the results.
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>
> Sent: Friday, March 21, 2008 2:44 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
>
>
> knowing the size and the window together seems like a ui requirement,
> it is a bit strange to me that you have it inside a dao which should
> cater to business logic. eg, as far as i know there is no single db
> operation that will produce both, so you are still doing two calls
> inside the dao.
>
> also transaction management should be handled outside the dao, daos
> are too fine an object to implement transaction management for.
>
> anywho, just nitpicking :)
>
> size() is called first for a lot of reasons, namely even knowing if
> there are any rows to retrieve before a much heavier iterator() is
> called. some clients want to hide a repeater if there are no items
> visible, and so size() might get called from inside isvisible() as
> well.
>
> idataprovider is quiet old and we havent had many complaints about its
> design so far. if all you are using is the dataview it should be
> pretty simple for you to roll your own dataview, if you look at
> dataview all it does is implement idataprovider handling to feed the
> pageable view. however, if you do you will also lose datatable as well
> :|
>
> if you got suggestions on how to improve it im all ears.
>
> -igor
>
>
> On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> > When using DataView/IDataProvider size() is called before iterator(int
> first, int count) causing calls to DAOs to be duplicated. Our current
> framework that is internally using Hibernate allows one call to be made to a
> DAO that returns both the total result size and the actual records (based off
> first/count). The problem is that the first and count are unknown until the
> iterator method is called- forcing multiple calls to the DAO to retrieve the
> data (also forcing multiple transactions). What are the
Re: DataView size() iterator() call order issue
how are we going to cover these usecases:
* pagination toolbar needs to call dataprovier.size() to figure out
how many total records there are. at this point the toolbar doesnt
know what window of data to retrieve, it just wants to know the size.
* often users do:
new dataview() { isvisible() { return dataprovider.size()>0; }
once again, datawindow size is not known.
-igor
On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> We are using a modified version of the Generic DAO for Hibernate
> (http://www.hibernate.org/328.html) where we make reuse of common DAO methods
> such as keyword searches that retrieve corresponding entities as well a total
> size (both use the same search criteria when determining results so it makes
> sense to combine the operations). As you stated, we are making two calls the
> database, but only one call to the DAO (although, as stated in previous
> responses there are alternative ways to perform one query to achieve this).
>
> Our business tier handles the transactions for us (not our DAOs ;o) using an
> event model (similar to typical BPM systems). Broadcast agents are used to
> notify our business listeners which in turn process our DAO calls. This gives
> us an the flexibility to have independent transactions for different business
> rule operations and makes the most out of code reuse.
>
> Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the operation were combined so that the implementation could
> determine how/when to make the call to the persistence tier for the two
> operations. I guess I'm not seeing why we need the count before the iterator.
> The data provider impl can determine whether or not it will make the
> expensive call for the results.
>
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>
> Sent: Friday, March 21, 2008 2:44 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
>
>
> knowing the size and the window together seems like a ui requirement,
> it is a bit strange to me that you have it inside a dao which should
> cater to business logic. eg, as far as i know there is no single db
> operation that will produce both, so you are still doing two calls
> inside the dao.
>
> also transaction management should be handled outside the dao, daos
> are too fine an object to implement transaction management for.
>
> anywho, just nitpicking :)
>
> size() is called first for a lot of reasons, namely even knowing if
> there are any rows to retrieve before a much heavier iterator() is
> called. some clients want to hide a repeater if there are no items
> visible, and so size() might get called from inside isvisible() as
> well.
>
> idataprovider is quiet old and we havent had many complaints about its
> design so far. if all you are using is the dataview it should be
> pretty simple for you to roll your own dataview, if you look at
> dataview all it does is implement idataprovider handling to feed the
> pageable view. however, if you do you will also lose datatable as well
> :|
>
> if you got suggestions on how to improve it im all ears.
>
> -igor
>
>
> On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> > When using DataView/IDataProvider size() is called before iterator(int
> first, int count) causing calls to DAOs to be duplicated. Our current
> framework that is internally using Hibernate allows one call to be made to a
> DAO that returns both the total result size and the actual records (based off
> first/count). The problem is that the first and count are unknown until the
> iterator method is called- forcing multiple calls to the DAO to retrieve the
> data (also forcing multiple transactions). What are the reasons behind
> calling size before iterator?
> >
> >
> > -
> > 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]
>
>
>
> -
> 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: DataView size() iterator() call order issue
We are using a modified version of the Generic DAO for Hibernate (http://www.hibernate.org/328.html) where we make reuse of common DAO methods such as keyword searches that retrieve corresponding entities as well a total size (both use the same search criteria when determining results so it makes sense to combine the operations). As you stated, we are making two calls the database, but only one call to the DAO (although, as stated in previous responses there are alternative ways to perform one query to achieve this). Our business tier handles the transactions for us (not our DAOs ;o) using an event model (similar to typical BPM systems). Broadcast agents are used to notify our business listeners which in turn process our DAO calls. This gives us an the flexibility to have independent transactions for different business rule operations and makes the most out of code reuse. Avoiding the heavier call makes perfect sense, but couldn't this responsibility be passed to the data provider implementation? It may make more sense if the operation were combined so that the implementation could determine how/when to make the call to the persistence tier for the two operations. I guess I'm not seeing why we need the count before the iterator. The data provider impl can determine whether or not it will make the expensive call for the results. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 2:44 PM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue knowing the size and the window together seems like a ui requirement, it is a bit strange to me that you have it inside a dao which should cater to business logic. eg, as far as i know there is no single db operation that will produce both, so you are still doing two calls inside the dao. also transaction management should be handled outside the dao, daos are too fine an object to implement transaction management for. anywho, just nitpicking :) size() is called first for a lot of reasons, namely even knowing if there are any rows to retrieve before a much heavier iterator() is called. some clients want to hide a repeater if there are no items visible, and so size() might get called from inside isvisible() as well. idataprovider is quiet old and we havent had many complaints about its design so far. if all you are using is the dataview it should be pretty simple for you to roll your own dataview, if you look at dataview all it does is implement idataprovider handling to feed the pageable view. however, if you do you will also lose datatable as well :| if you got suggestions on how to improve it im all ears. -igor On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> wrote: > When using DataView/IDataProvider size() is called before iterator(int first, > int count) causing calls to DAOs to be duplicated. Our current framework that > is internally using Hibernate allows one call to be made to a DAO that > returns both the total result size and the actual records (based off > first/count). The problem is that the first and count are unknown until the > iterator method is called- forcing multiple calls to the DAO to retrieve the > data (also forcing multiple transactions). What are the reasons behind > calling size before iterator? > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DataView size() iterator() call order issue
On Fri, Mar 21, 2008 at 1:32 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > Well, there could be savings in the amount of code. i dont buy this, at the very minimum you will have a helper that does counts no matter how you are accessing the db > You also could save by reducing the transactions to 1. i dont buy this either. it doesnt scale. if you have two dataviews you probably want those two requests to be executed in the same transaction also. so transaction boundaries need to be managed on a higher level. > I'm not saying DataView should work with > this, I'm just saying that's a way to get the count and the list > simultaneously. i get it. im just trying to rationalize why and how the design choice of idataprovider was made. -igor > > > -Original Message- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > > Sent: Friday, March 21, 2008 1:27 PM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > yes you can technically mangle it into a single query and get a single > result set back, but where is your savings? the database is still > doing two operations... > > not to mention once you include any sort of filtering you have to > repeat your where clause in both the main select and the subselect... > > -igor > > > On Fri, Mar 21, 2008 at 1:23 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > > FYI, in oracle you can use Analytical Functions to do this in one query. > In > > other db's you can do this: > > select username, x.* from customlist, (select count(*) from customlist) > as > > x; > > > > > > > > -Original Message- > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 21, 2008 11:44 AM > > To: users@wicket.apache.org > > Subject: Re: DataView size() iterator() call order issue > > > > knowing the size and the window together seems like a ui requirement, > > it is a bit strange to me that you have it inside a dao which should > > cater to business logic. eg, as far as i know there is no single db > > operation that will produce both, so you are still doing two calls > > inside the dao. > > > > also transaction management should be handled outside the dao, daos > > are too fine an object to implement transaction management for. > > > > anywho, just nitpicking :) > > > > size() is called first for a lot of reasons, namely even knowing if > > there are any rows to retrieve before a much heavier iterator() is > > called. some clients want to hide a repeater if there are no items > > visible, and so size() might get called from inside isvisible() as > > well. > > > > idataprovider is quiet old and we havent had many complaints about its > > design so far. if all you are using is the dataview it should be > > pretty simple for you to roll your own dataview, if you look at > > dataview all it does is implement idataprovider handling to feed the > > pageable view. however, if you do you will also lose datatable as well > > :| > > > > if you got suggestions on how to improve it im all ears. > > > > -igor > > > > > > On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> > > wrote: > > > When using DataView/IDataProvider size() is called before iterator(int > > first, int count) causing calls to DAOs to be duplicated. Our current > > framework that is internally using Hibernate allows one call to be made > to a > > DAO that returns both the total result size and the actual records (based > > off first/count). The problem is that the first and count are unknown > until > > the iterator method is called- forcing multiple calls to the DAO to > retrieve > > the data (also forcing multiple transactions). What are the reasons > behind > > calling size before iterator? > > > > > > > > > - > > > 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] > > > > > > - > > 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] > > > - > 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: DataView size() iterator() call order issue
Well, there could be savings in the amount of code. You also could save by reducing the transactions to 1. I'm not saying DataView should work with this, I'm just saying that's a way to get the count and the list simultaneously. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 1:27 PM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue yes you can technically mangle it into a single query and get a single result set back, but where is your savings? the database is still doing two operations... not to mention once you include any sort of filtering you have to repeat your where clause in both the main select and the subselect... -igor On Fri, Mar 21, 2008 at 1:23 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > FYI, in oracle you can use Analytical Functions to do this in one query. In > other db's you can do this: > select username, x.* from customlist, (select count(*) from customlist) as > x; > > > > -Original Message- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Friday, March 21, 2008 11:44 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > knowing the size and the window together seems like a ui requirement, > it is a bit strange to me that you have it inside a dao which should > cater to business logic. eg, as far as i know there is no single db > operation that will produce both, so you are still doing two calls > inside the dao. > > also transaction management should be handled outside the dao, daos > are too fine an object to implement transaction management for. > > anywho, just nitpicking :) > > size() is called first for a lot of reasons, namely even knowing if > there are any rows to retrieve before a much heavier iterator() is > called. some clients want to hide a repeater if there are no items > visible, and so size() might get called from inside isvisible() as > well. > > idataprovider is quiet old and we havent had many complaints about its > design so far. if all you are using is the dataview it should be > pretty simple for you to roll your own dataview, if you look at > dataview all it does is implement idataprovider handling to feed the > pageable view. however, if you do you will also lose datatable as well > :| > > if you got suggestions on how to improve it im all ears. > > -igor > > > On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > When using DataView/IDataProvider size() is called before iterator(int > first, int count) causing calls to DAOs to be duplicated. Our current > framework that is internally using Hibernate allows one call to be made to a > DAO that returns both the total result size and the actual records (based > off first/count). The problem is that the first and count are unknown until > the iterator method is called- forcing multiple calls to the DAO to retrieve > the data (also forcing multiple transactions). What are the reasons behind > calling size before iterator? > > > > > > - > > 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] > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DataView size() iterator() call order issue
yes you can technically mangle it into a single query and get a single result set back, but where is your savings? the database is still doing two operations... not to mention once you include any sort of filtering you have to repeat your where clause in both the main select and the subselect... -igor On Fri, Mar 21, 2008 at 1:23 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > FYI, in oracle you can use Analytical Functions to do this in one query. In > other db's you can do this: > select username, x.* from customlist, (select count(*) from customlist) as > x; > > > > -Original Message- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Friday, March 21, 2008 11:44 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > knowing the size and the window together seems like a ui requirement, > it is a bit strange to me that you have it inside a dao which should > cater to business logic. eg, as far as i know there is no single db > operation that will produce both, so you are still doing two calls > inside the dao. > > also transaction management should be handled outside the dao, daos > are too fine an object to implement transaction management for. > > anywho, just nitpicking :) > > size() is called first for a lot of reasons, namely even knowing if > there are any rows to retrieve before a much heavier iterator() is > called. some clients want to hide a repeater if there are no items > visible, and so size() might get called from inside isvisible() as > well. > > idataprovider is quiet old and we havent had many complaints about its > design so far. if all you are using is the dataview it should be > pretty simple for you to roll your own dataview, if you look at > dataview all it does is implement idataprovider handling to feed the > pageable view. however, if you do you will also lose datatable as well > :| > > if you got suggestions on how to improve it im all ears. > > -igor > > > On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > When using DataView/IDataProvider size() is called before iterator(int > first, int count) causing calls to DAOs to be duplicated. Our current > framework that is internally using Hibernate allows one call to be made to a > DAO that returns both the total result size and the actual records (based > off first/count). The problem is that the first and count are unknown until > the iterator method is called- forcing multiple calls to the DAO to retrieve > the data (also forcing multiple transactions). What are the reasons behind > calling size before iterator? > > > > > > - > > 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] > > > - > 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: DataView size() iterator() call order issue
FYI, in oracle you can use Analytical Functions to do this in one query. In other db's you can do this: select username, x.* from customlist, (select count(*) from customlist) as x; -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 11:44 AM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue knowing the size and the window together seems like a ui requirement, it is a bit strange to me that you have it inside a dao which should cater to business logic. eg, as far as i know there is no single db operation that will produce both, so you are still doing two calls inside the dao. also transaction management should be handled outside the dao, daos are too fine an object to implement transaction management for. anywho, just nitpicking :) size() is called first for a lot of reasons, namely even knowing if there are any rows to retrieve before a much heavier iterator() is called. some clients want to hide a repeater if there are no items visible, and so size() might get called from inside isvisible() as well. idataprovider is quiet old and we havent had many complaints about its design so far. if all you are using is the dataview it should be pretty simple for you to roll your own dataview, if you look at dataview all it does is implement idataprovider handling to feed the pageable view. however, if you do you will also lose datatable as well :| if you got suggestions on how to improve it im all ears. -igor On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> wrote: > When using DataView/IDataProvider size() is called before iterator(int first, int count) causing calls to DAOs to be duplicated. Our current framework that is internally using Hibernate allows one call to be made to a DAO that returns both the total result size and the actual records (based off first/count). The problem is that the first and count are unknown until the iterator method is called- forcing multiple calls to the DAO to retrieve the data (also forcing multiple transactions). What are the reasons behind calling size before iterator? > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DataView size() iterator() call order issue
knowing the size and the window together seems like a ui requirement, it is a bit strange to me that you have it inside a dao which should cater to business logic. eg, as far as i know there is no single db operation that will produce both, so you are still doing two calls inside the dao. also transaction management should be handled outside the dao, daos are too fine an object to implement transaction management for. anywho, just nitpicking :) size() is called first for a lot of reasons, namely even knowing if there are any rows to retrieve before a much heavier iterator() is called. some clients want to hide a repeater if there are no items visible, and so size() might get called from inside isvisible() as well. idataprovider is quiet old and we havent had many complaints about its design so far. if all you are using is the dataview it should be pretty simple for you to roll your own dataview, if you look at dataview all it does is implement idataprovider handling to feed the pageable view. however, if you do you will also lose datatable as well :| if you got suggestions on how to improve it im all ears. -igor On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]> wrote: > When using DataView/IDataProvider size() is called before iterator(int first, > int count) causing calls to DAOs to be duplicated. Our current framework that > is internally using Hibernate allows one call to be made to a DAO that > returns both the total result size and the actual records (based off > first/count). The problem is that the first and count are unknown until the > iterator method is called- forcing multiple calls to the DAO to retrieve the > data (also forcing multiple transactions). What are the reasons behind > calling size before iterator? > > > - > 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]
DataView size() iterator() call order issue
When using DataView/IDataProvider size() is called before iterator(int first, int count) causing calls to DAOs to be duplicated. Our current framework that is internally using Hibernate allows one call to be made to a DAO that returns both the total result size and the actual records (based off first/count). The problem is that the first and count are unknown until the iterator method is called- forcing multiple calls to the DAO to retrieve the data (also forcing multiple transactions). What are the reasons behind calling size before iterator? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
