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