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<MODEL> iterator(final int first, final int count) {" to: public final Iterator<MODEL> 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 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] --------------------------------------------------------------------- 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]
