Ah, just a semantic change, then: in the viewer, refer to page, but in the object store refer to Range. The viewer paging code uses the DB range API.
I would prefer not to split into two verbs. I would guess that most DB developers would know what "paged" access is referring to. Jeroen van der Wal <[email protected]> wrote: >You misinterpreted my comment: the concept of paging is something that >lives in the context of a viewer. When it comes to querying data I >prefer >to reuse the word range over paging. So the paging feature of a viewer >would call a range feature in the query class. > > >On Wed, Feb 6, 2013 at 10:15 AM, Mike Burton ><[email protected]>wrote: > >> Sorry to be brief >> See "Paging is IMHO..." Below >> >> Best Regards >> >> Mike Burton >> (Sent from my iPhone) >> >> >> On 6 Feb 2013, at 08:46, Jeroen van der Wal <[email protected]> >wrote: >> >> > On Wed, Feb 6, 2013 at 8:20 AM, Dan Haywood < >> [email protected]>wrote: >> > >> >> On 6 February 2013 02:16, Kevin Meyer <[email protected]> wrote: >> >> >> >>> Hi Dan, >> >> >> >>> >> >>> So, sure, I guess I can look into enhancing QueryAbstract with >optional >> >>> parameters. >> >> +1 >> > +1 too >> > >> >> >> >> How about a new withPaging(start, count) method, eg: >> >> >> >> public class QueryAbstract { >> >> >> >> ... >> >> public QueryAbstract withPaging(int start, int count) { >> >> this.start = start; >> >> this.count = count; >> >> return this; >> >> } >> >> >> >> } >> > Paging is IMHO a concept that lives in the viewer. >> >> Doesn't sound right to me, would that mean viewer needed to fetch >whole >> set then chop it into pages? >> >> > When it comes to >> > querying data I opt to adapt the JDO concept "Range" [1] i.e. >> setRange(int >> > start, int end) or withRange(int start, int end) >> > >> > [1] >> > >> >http://db.apache.org/jdo/api20/apidocs/javax/jdo/Query.html#setRange(long, >> > long) >> > >> > >> >> >> >> >> >>> >> >>> 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). >> >> >> >> I'm happy with those names (rather than start/end) >> >> >> >> >> >>> >> >>> 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. >> >>> >> >>> OK, thx. The thing about search by title is that - to be >efficient - >> it >> >> requires that the objectstore has persisted the title in a column >> >> somewhere. I'd rather that the programmer decides to do this >> explicitly >> >> (eg by having a hidden property that holds the title and search on >that) >> >> than have the framework do some magic. >> >> >> >> ie, if the programmer really wants to support search by title, >they can >> >> just do: >> >> >> >> public class ToDoItem { >> >> >> >> >> >> @Title >> >> @Hidden >> >> public String getTitle() { ... } >> >> public void setTitle(String t) { ... } >> >> >> >> private void recomputeTitle() { // call whenever a component >part >> of >> >> title has changed >> >> setTitle(....); >> >> } >> >> >> >> } >> >> >> >> Dan >> >> >> >> Regards, >> >>> Kevin >> >> >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
