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