RE: totalItems with pagination and filtering

On 27 Nov 2015 at 22:48, Karol Szczepański wrote:
>> 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.

So you are saying that while it is possible to attach a view to a collection, the opposite is impossible? That's not true. The fact that the inverse property isn't materialized doesn't mean anything. Just use @reverse in your context.

   "viewOf": { "@reverse": "hydra:view" }

As soon as the vocabulary is stable, we will decide what to put in Hydra's default context to make this trivial for everyone to use.

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

In what aspects does a filtered view differ from a partial view? That was exactly the reason why I did *not* want to call this PaginatedCollectionView.


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

Right, but that's not what we are discussing here. The issue is that in the first reponse the server tells us

  "The /users resource is a collection and it has 50 members"

In the second response it tells us

  "The /users resource is a collection and it has 10,000 members"

The first reponse doesn't tell us how many items the partial/filtered view/collection has.


> 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

Right. This is what we need to discuss. Perhaps we come up with a more elegant, intuitive solution.

So, the main questions IMO are:
  - if a collection is filtered, how do we express the number of items
    that match the filter?
  - if a collection is filtered and paginated, how do we express the
    number of items that match the filter?
  - if a collection is filtered and paginated, do we want/need to express
    the number of items of a single?


--
Markus Lanthaler
@markuslanthaler

Received on Saturday, 28 November 2015 15:12:28 UTC