chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Caruana <david.caru...@alfresco.com>
Subject Re: PagingIterable
Date Fri, 23 Apr 2010 16:33:25 GMT
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
> <david.caruana@alfresco.com> 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:david.caruana@alfresco.com]
>>> Sent: Freitag, 23. April 2010 14:35
>>> To: chemistry-dev@incubator.apache.org
>>> 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


Mime
View raw message