Ok, well I have an implementation of getPage() without an explicit maxItems parameter. I'll finish the tests and then checkin.
We can then follow up with the next refactor which: - renames PagingIterable to the chosen name :-) - removes "maxItems" from the service calls - adds maxItems to OperationContext - adds a getPage(int maxItems) Dave On 23 Apr 2010, at 17:21, Florent Guillaume wrote: > Hi, > > I would propose SkippableIterable for the new name. It describes what > this does, "Item" is a bit meaningless. > > Regarding simplified APIs I like them. Putting a default page size in > the OperationContext is good. When using the API, I'd like it to be > possible for a client to not care at all about page sizes, and let it > assume that "the system" will choose appropriate defaults. > > Florent > > > > > On Fri, Apr 23, 2010 at 4:58 PM, David Caruana > <[email protected]> wrote: >> With the MIX option, I assume you also propose to remove the "maxItems" >> parameter from service calls. >> >>> PagingIterable<QueryResult>) results = session.query("select ...", false); >> >>> for (QueryResult result : results) { ... } >>> for (QueryResult result : results.skipTo(100)) { ... } >>> for (QueryResult result : results.getPage()) { ... } >> >> >>> for (QueryResult result : results.getPage(10)) { ... } >>> for (QueryResult result : results.skipTo(100).getPage()) { ... } >> >>> for (QueryResult result : results.skipTo(100).getPage(10)) { ... } >> >> >> I'm ok with this, as long as there is some way of defining a session or >> OperationContext default for maxItems, for the case where a client iterates >> through all items in the CMIS collection. >> >> Any other proposals or thoughts from anyone? >> >> Dave >> >> On 23 Apr 2010, at 14:12, Klevenz, Stephan wrote: >> >>> Hi Dave, >>> >>> Good coding example. Between our two proposals is only a little difference >>> and also a mix is possible: >>> >>> YOU: PagingIterable<QueryResult>) results = session.query("select ...", >>> false, 10); >>> ME: PagingIterable<QueryResult>) results = session.query("select ...", >>> false); >>> >>> YOU: for (QueryResult result : results.getPage()) { ... } >>> ME: for (QueryResult result : results.skipTo(0, 10)) { ... } >>> MIX: for (QueryResult result : results.getPage(10)) { ... } >>> >>> YOU: for (QueryResult result : results.skipTo(100).getPage()) { ... } >>> ME: for (QueryResult result : results.skipTo(100, 10)) { ... } >>> MIX: for (QueryResult result : results.skipTo(100).getPage(10)) { ... } >>> >>> From functional point of view it's all the same. Free choice :-) I'd like >>> the MIX. >>> >>> Regards, >>> Stephan >>> >>> -----Original Message----- >>> From: David Caruana [mailto:[email protected]] >>> Sent: Freitag, 23. April 2010 14:35 >>> To: [email protected] >>> Subject: Re: PagingIterable >>> >>> Hi Stephan, >>> >>> I'm currently experimenting with the new PagingIterable in the context of a >>> simple query web page. So, have some thoughts on your discussion points. >>> >>> On 23 Apr 2010, at 13:06, Klevenz, Stephan wrote: >>> >>>> Hi, >>>> >>>> One follow up task after F2F was to finish the implementation of the >>>> PagingIterable interface. This is finished now. >>>> >>>> In the client impl module you'll find a unit test testing the default >>>> implementation. In FIT module all APIs returning an Iterable are also >>>> covered by basic unit tests. >>>> >>>> I have open points for discussion: >>>> >>>> a) Naming: Actually the interface behaves like an interval. Paging is >>>> more or less an optimization of the implementation not to read all >>>> elements in one call. My naming proposal would be "ItemIterable" for >>>> CmisObjects, QueryResults, Events, ObjectTypes ... >>> >>> +1 >>> >>>> b) Paging Parameter or itemsPerPage: Used in all API returning an >>>> Iteable e.g. >>>> >>>> PagingIterable<Document> getCheckedOutDocs(int itemsPerPage); >>>> >>>> As said this is more an optimization rather than a real page which should >>>> have a begin and an end. I propose to eliminate this parameter in API and >>>> assign it to the session (or OperationContext) as a global optimization >>>> parameter. >>> >>> If the parameter is removed, I'd like to see it at least available in >>> OperationContext. >>> >>>> c) SkipCount: Because of totalNumItems is an optional value (s. CMIS >>>> 2.2.1.1) an application can not necessarily calculate the maximum of >>>> skipCount parameter. Current implementation runs out of bound if skipCount >>>> > totalNumItems. This is maybe a bug and it would be better implementation >>>> accepts a high skipCount. In that case the Iterable returns not more items. >>> >>> Seems like a bug. +1 to return false for hasNext() in this case. >>> >>>> d) skipTo(pos): I propose another (optional) parameter maxItems for >>>> this method. Currently the Iterable returns all elements. >>> >>> I'm experimenting with an additional getPage() method on PagingIterable. >>> This returns an Iterable for the current page of items only. This is >>> similar to your proposal except it inherits the maxItems from the provided >>> page fetcher. >>> >>> So, if you execute a query as such: >>> >>> PagingIterable<QueryResult>) results = session.query("select ...", false, >>> 10); >>> >>> You can iterate through all rows as such: >>> >>> for (QueryResult result : results) { ... } >>> >>> You can iterate through all rows from specified starting position: >>> >>> for (QueryResult result : results.skipTo(100)) { ... } >>> >>> You can iterate through a page of rows: >>> >>> for (QueryResult result : results.getPage()) { ... } >>> >>> for (QueryResult result : results.skipTo(100).getPage()) { ... } >>> >>> e) I'd also like to propose the additional method hasMoreItems() on >>> PagingIterable which allows access to the hasMoreItems output parameter of >>> CMIS services which return collections. >>> >>>> Let me know what do you think. >>>> >>>> Regards, >>>> Stephan >>>> >>>> >>>> >>> >> >> > > > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
