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 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] > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >