Re: totalItems with pagination and filtering

>On 26 Nov 2015 at 22:25, Karol Szczepański wrote:
>> On 26 Nov 2015 at 16:30, Markus Lanthaler wrote:
>>> An alternative would be to allow to attach totalItems to
>>> PartialCollectionView in case it differs from the underlying collection:
>>>  {
>>>    "@id": "/users",
>>>    "@type": "Collection",
>>>    "member": [ ...10 Bob items... ],
>>>    "totalItems": 10000,
>>>    "view":
>>>      "@id": "/users?name=Bob&p=1",
>>>      "@type": "PartialCollectionView",
>>>      "totalItems": 50,
>>>      "first": "/users?name=Bob&p=1",
>>>      "next": "/users?name=Bob&p=2",
>>>      "last": "/users?name=Bob&p=5"
>>>    }
>>>  }
>>> ... which looks much simpler but may be conceptually ambiguous.
>>
>> This ambiguoity comes from a collection and it's view representation, not
>> the opposite.
>I don't understand the above sentence.
We're describing a collection and attaching a view as a value of a 
collection's relation. There is no symmetric relation so we could describe 
the view directly and point to a collection.

>> Finally we'll need totalItems for both as attaching it only
>> the collection and still having a view is somehow unnatural.
>Why? If you just paginate a collection, the two would be equal.
I'll state it again - paging is just a type of view. What about other, i.e. 
filtered?

>> I'm not sure where is the problem here. There is nothing against a
>> server to return this to GET /users?name=Bob&p=1:
>>
>> {
>> "@id": "/users",
>> "@type": "Collection",
>> "member": [ ...10 Bob items... ],
>> "totalItems": 50,
>> "view": {
>>   "@id": "/users?name=Bob&p=1",
>>   "@type": "PartialCollectionView",
>>   "first": "/users?name=Bob&p=1",
>>   "next": "/users?name=Bob&p=2",
>>   "last": "/users?name=Bob&p=5"
>> }
>> }
>>
>> while for GET /users it would return just return this:
>>
>> {
>> "@id": "/users",
>> "@type": "Collection",
>> "member": [ ...all items... ],
>> "totalItems": 10000
>> }
>
>The problem is that the server would lie. In the first response it says 
>that /users has 50 items and in the second it says it has 10,000.
Disagree. First request has a different Url that the second, thus assumption 
that both request should return same data is somehow incorrect.
But still - this is an alternateting route for my previous suggestion of 
having totalItems for both collection and it's view. We have three options 
here:
1. totalItems only in the collection - situation described above
2. totalItems only in the view - what would happen if the collection doesn't 
have a view at all?
3. totalItems for both - somehow unnatural

>>>>> To help think about it, let's imagine we subclass Collection and use
>>>>> something like FilteredCollection which could then include some custom
>>>>> predicates like "appliedFilter": {"name": "Bob"}, and the link to the
>>>>> unfiltered collection which should be unambiguous.
>>>
>>> How would a FilteredCollection differ from a PartialCollectionView?
>>
>> I think this is is due to a "unlucky" PartialCollectionView name.
>> PartialCollectionView is a view already, but it's name suggests it's only
>> for pages.
>
>Did you mean "it's only for collections"? We are discussing collections 
>here.
But filtering can be applied also to collections resulting effectively with 
a view and it doesn't imply that this view can be also a subject for 
pagination.
In order to avoid specialized classes for various types of collection views 
which doesn't introduce any thing new to the base model, we should stick to 
some more generic naming.

>>> I think I suggested something more generic like PartialView -
>>> this would avoid such situations.
>>
>You didn't AFAICT :-)
Maybe not directly, we had discussions about names in several situations.

>>>> Your idea seems sound. I'd have to defer that to other on this list for
>>>> detailed discussion. My thought is that the "appliedFilter" is
>>>> essentially an instance of a IriTemplate with variables filled in. I
>>>> would model it with the IriTemplate in mind.
>>
>> We somehow start to have this discussion in several places (Ruben's
>> hydra:filter not to look to far). Maybe it's worth of starting a
>> separate discussion on whether we want anything other than paging in the
>> core or not and if we want, how should we approach filtering or in
>> general view crafting?
>
>Yeah, the discussion is split between a few threads. We also have
>
>  https://www.w3.org/community/hydra/wiki/Client-initiated_pagination
I remember - put some features there

Karol

Received on Friday, 27 November 2015 21:49:11 UTC