[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [odata-comment] Order in JSON response "MUST"
|
Hi Jovan, ·
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 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 From:
odata-comment@lists.oasis-open.org [mailto:odata-comment@lists.oasis-open.org]
On Behalf Of Christian Müller Hi all, 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. Best, Christian |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]