[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [odata-comment] Order in JSON response "MUST"
|
This is great feedback. I’ve opened
ODATA-896 to track this specific issue (position of odata.count). @Jovan - I think the requirement on position probably originally came from a streaming perspective… many clients may use the count in advance to track things
as they come in, and since most responses are paged anyway, we’ll often see the need for a separate database hit to calculate the count (hopefully just a SELECT COUNT(*) FROM … WHERE …). On the plus side, this is part of why we have the vocabularies to describe
what requests the service is willing to honor. @Christian – As I mentioned to Jovan, a lot of the ordering constraints you’ll see in the spec are related in some way/shape/form to streaming. For instance,
in our .NET stacks, we operate under the assumption that you can only ever have one entity type in memory (because maybe that entity is extremely large). If we have to read to the end of the JSON object to get type information to know what to materialize,
things get a lot less efficient in general. So, could we relax *all* of the payload ordering constraints? Probably, but do please realize that many of them are there for a reason. I do agree that the case you pointed out seems overspecified. It should be SHOULD as opposed to MUST. Sometimes we miss things in standards, which is part of
the reason they’re living documents and we iterate on them. I do hope you’ll feel free to send in additional feedback if you find other areas of the protocol that seem problematic. Thanks, 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]