On Fri, Mar 21, 2008 at 1:32 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > Well, there could be savings in the amount of code.
i dont buy this, at the very minimum you will have a helper that does counts no matter how you are accessing the db > You also could save by reducing the transactions to 1. i dont buy this either. it doesnt scale. if you have two dataviews you probably want those two requests to be executed in the same transaction also. so transaction boundaries need to be managed on a higher level. > I'm not saying DataView should work with > this, I'm just saying that's a way to get the count and the list > simultaneously. i get it. im just trying to rationalize why and how the design choice of idataprovider was made. -igor > > > -----Original Message----- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > > Sent: Friday, March 21, 2008 1:27 PM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > yes you can technically mangle it into a single query and get a single > result set back, but where is your savings? the database is still > doing two operations... > > not to mention once you include any sort of filtering you have to > repeat your where clause in both the main select and the subselect... > > -igor > > > On Fri, Mar 21, 2008 at 1:23 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > > FYI, in oracle you can use Analytical Functions to do this in one query. > In > > other db's you can do this: > > select username, x.* from customlist, (select count(*) from customlist) > as > > x; > > > > > > > > -----Original Message----- > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 21, 2008 11:44 AM > > 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]
