OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

 

 

From: odata-comment@lists.oasis-open.org [mailto:odata-comment@lists.oasis-open.org] On Behalf Of Christian Müller
Sent: Tuesday, December 15, 2015 12:23 PM
To: odata-comment@lists.oasis-open.org
Subject: [odata-comment] Order in JSON response "MUST"

 

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]