[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (ODATA-157) Specify how client correlates requests within a changeset with responses
[ http://tools.oasis-open.org/issues/browse/ODATA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31816#action_31816 ]
Ralf Handl commented on ODATA-157:
----------------------------------
A service may dispatch the GET requests in the top level of the batch request to several worker threads. Why impose on it to buffer all the query results just to return them in the request sequence? The server may stream back the responses from the fastest queries first.
I find the streaming argument more convincing with GET requests, as per default PUT and DELETE requests return 204 No Content, which is easier to buffer than 100 sales orders with expanded items.
And if clients (or the libraries they use) have to learn generating unique content-ids into request parts, then we can require that for all request types and give the servers complete freedom on how to assemble the response.
> Specify how client correlates requests within a changeset with responses
> ------------------------------------------------------------------------
>
> Key: ODATA-157
> URL: http://tools.oasis-open.org/issues/browse/ODATA-157
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Bug
> Components: OData Protocol v1.0
> Affects Versions: WD01
> Environment: [Proposed]
> Reporter: Michael Pizzo
> Assignee: Michael Pizzo
> Fix For: WD01
>
>
> The current $batch specification says that requests within a changeset need not be processed in the same order they are specified. For example, a service may re-order changes to reduce the likelihood of integrity violations by first doing deletes, then inserts, then updates. It goes on to say that the responses in a changeset must be 1:1 with the requests, but does not say they must be in the same order, and does not say how a client correlates a response within a changeset with a particular request within that changeset.
> Changesets do describe the use of a content-id header for allowing a statement within a batch to reference the results of a previous statement within the batch. For example, to add an order to a customer that was added within the same batch. However, it does not say that it is mandatory for the client to specify the content-id header for requests within a batch, nor does it say that it is mandatory for a service to return content-id headers supplied within the batch.
> It seems simplest to say that clients SHOULD specify a content-id header for requests within a changeset, and that service MUST return the content-id (if any) specified by the client. This allows the service to re-order changes within the changeset without having to buffer the response, and is arguably simpler for the client to correlate responses without having to rely on ordering.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]