Hi Dan, My main reason for introducing the new query rather than enhancing the existing ones, was for minimum impact.
I certainly don't think that the existing queries must not be enhanced, it was more that "they've been fine so far, so how do I introduce this new functionality?" I was also testing the waters, so to speak. So, sure, I guess I can look into enhancing QueryAbstract with optional parameters. Does anyone have anything to add regarding method signature? Start and count vs start and end, for example? I think start and cound is more obvious (and couples with the paging annotation). As for your other question: I used "find by pattern" quite nicely in my deployed app, so I'd like to see it preserved. Find by title is a simple specific implementation of pattern, but could be useful... dunno. Regards, Kevin Dan Haywood <[email protected]> wrote: >Hi Kev, > >Just picking up on this change that you've now also implemented in >ISIS-220 >and ISIS-221. (Sorry I didn't reply earlier on this topic, but at >least >now I can see from the code what your intent was/is). > >The issue I have, I think (and I'm kinda thinking aloud here) is that >the >paging support ought to apply to all the subtypes of QueryAbstract (in >the >applib) and the corresponding subtypes of PersistentQueryAbstract. > >For the record (and for anyone following this who wants to know more) >the >original four subtypes were: > >* QueryFindAllInstances & PersistentQueryFindAllInstances - simply >"select >*" >* QueryFindByPattern & PersistentQueryFindByPattern - a query by >example >using a prototype "pattern" object >* QueryFindByTitle & PersistentQueryFindByTitle - search for an object >by >its title >* QueryDefault & PersistenceQueryFindUsingApplibQueryDefault - >execute a >named query (eg a stored procedure or prepared statement) > > >From what I see, you've now created a new subtype: > >* QueryFindPaged & PersistentQueryFindPaged - simply "select *" plus >start, >count > >However, I can see that this is paging support is orthogonal to the >original four; in other words it ought to be that all four of the query >subtypes should be enhanced. Rather than having 8 subtypes, I think >I'd >rather that they all have an optional paging parameters. > >What say you? > >~~~ >While on this topic and looking at the JDO objectstore, I see that >while I >implemented the "AllInstances" (select *") and "Default" (named >queries), I >haven't yet implemented support for finding by pattern or by title. >This >is functionality from the early days of Isis' precursor, Naked Objects >framework. So, can I ask.... what do we feel about it... is it a >feature >people want preserved, or not? [perhaps this should be a separate >thread] > >Dan > > >On 27 January 2013 16:41, Kevin Meyer - KMZ <[email protected]> wrote: > >> Hi all, >> >> I'm looking at what is required to add paging support to the >datastore >> API and expose it to the user / viewer. >> >> Use case 1: a viewer finds a property that is a collection. When >> rendering the collection, it can either render all items, or just a >> subsection. >> >> Use case 2: The domain object wants to provide just the first (few) >> instances from a dataset (instead of all of them) for a "choicesXxxx" >> method. >> >> There'll be others.. >> >> In any case, I see two immediate requirements: >> 1) extend the PersistenceQuery implementations to include a >> PersistenceQueryPaged, which can be used by >> AbstractContainedObject, >> >> 2) Extend DomainObjectContainer to expose a paged method, such >> as "pagedInstances(int start, int count, Class<T> ofType)" >> >> Does this sound right? Any better suggestions? >> >> I'll leave off mechanisms to track current page, total page count, >etc, >> for the moment (although it does imply a "countInstancesOf" method). >> >> I presume the @Paged annotation can be picked up and used to >> guide the paging process... >> >> Regards, >> Kevin >> >> -- >> Kevin Meyer >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
