Hi Kevin, First off, I think we should distinguish between results that are rendered in the UI, vs those that are only ever returned to a domain object.
You have the latter case, and my feeling is that the SQL OS shouldn't really limit the rows. But since the SQL OS can't really "tell" how it is being called, it probably implies that it should always return all the rows, and then (for the former case) that the viewer layer should take responsibility for paging. It is a presentation concern, after all. I agree it would be worth adding some additional infrastructure into the Object Store API, eg some additional parameters that can be used by the viewer to request rows 1~100, 101~200 etc. fyi, in the NO MVC .NET impl, this is done reaonably transparently by returning an IQueryable<T>. It's still the viewer that does the paging though. I suspect I'll be seeing a new JIRA ticket being raised for this...? Dan On 23 March 2012 13:59, Kevin Meyer - KMZ <[email protected]> wrote: > Hi guys, > > At the moment, the SQL object store defaults to instantiating no more > than 100 instances of any POJO (e.g. allInstances(Member.class) will > only return up to 100 Members). > > I have added the ablity to increase this maximum via the properties file > (e.g. use: "isis.persistor.sql.maxinstances=1000"). > > What's the general rule here? > > Real world example: I want to generate an invoice for all NORMAL > members for their dues this year. From a pure design point of view, I > therefore want to use a pattern query to fetch all NORMAL members, > then with each member, create an invoice. Neither the list of members > nor the created invoices is ever presented to the UI. > > As it stands right now, I need to increase the maxinstances value. > > I don't really want to fire off a custom SQL query to create the invoice > entries manually... > > Regards, > Kevin > >
