Hi Jovan,
One reason I can think of is that a
client may want to know how many records are to be expected. Having
this information in the first chunk of a chunked result allows
to
·
Render
that number above the table control that will contain the results,
increasing the perceived responsiveness of the UI
·
Adjust
the scroll bar to the approximately correct size
·
Prepare
data containers in the model for receiving the data
Regarding implementation: many clients will combine $count=true
with $filter, $top, and $skip, so the count value will be the
number of results matching the $filter, while the number of results
contained in the response is determined by $top, which can be
orders of magnitude smaller, e.g. $top=50 out of
@odata.count:321043290342348 results matching the $filter. This
means that the count will have to be retrieved via a separate
SELECT COUNT(*) WHERE <$filter> which can be executed in
parallel to SELECT <$select> LIMIT <$top> OFFSET
<$skip> WHERE <$filter>.
Also services can decide to respond with a partial response and a
next-link, in which case the @odata.count is expected in the first
partial response, even if we relax the strange ordering
constraint.
Thanks for the feedback, and don’t hesitate to contact us if you
further strange requirements!
--Ralf
From:
odata-comment@lists.oasis-open.org
[mailto:odata-comment@lists.oasis-open.org] On Behalf Of
Jovan Popovic
Sent: Dienstag, 15. Dezember 2015 12:54
To: Christian Müller <christian@flownative.com>;
odata-comment@lists.oasis-open.org
Subject: RE: [odata-comment] Order in JSON response
"MUST"
I agree. That is one strange requirement.
It also affects OData implementations that use database
systems.
If you generate response from database you will naturally first
select all table rows that should be returned, and then read number
of returned entries using the length of collection or using
@@ROWCOUNT variable. In RDBMS count is available after result
set.
If the result set can be generated before count, providers can
simply stream results to client, and when all objects are sent,
OData service can append count as additional info in response body.
In this scenario generated object are not blocked.
With the current requirement, implementations must hold all results
until the last record is taken from database, then they can
calculate count of records and then flush both count and entire
result set.
Is there some reason why would we like to have count before result
set?
Regards,
Jovan
I
am new here and currently working on a OData implementation and
reading the spec a lot.
I
stumbled upon the following sentence in:
"The
odata.count name/value pair represents
the number of entities in the collection. If present, it MUST come
before the value name/value
pair."
I
am very irritated by the "MUST come before the value name/value
pair". IMHO that violates the JSON spec and should be
removed.
To
cite JSON spec: "An object is an unordered set of name/value
pairs". And many implementations treat it like that, which means
the order
is
not guaranteed if you use JSON tools of your language. The only way
to make sure this piece of the OData spec is respected
would
be using raw string operations. So I propose to remove all notions
of order of keys in the JSON format spec.