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: [email protected] 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: [email protected] > 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: [email protected] > > 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: [email protected] > > > 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: [email protected] > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
