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.

> 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'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.

 
>>>> 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.

> I think I suggested something more generic like PartialView -
> this would avoid such situations.

You didn't AFAICT :-)


>>> 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


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 27 November 2015 20:36:17 UTC