[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=31880#action_31880 ]
Michael Pizzo commented on ODATA-157:
-------------------------------------
The GET scenario is better served by returning Accepted in the batch an allowing the client to fetch as they are available. For changesets, the results are required to be atomic so the changeset cannot return success or failure until all of the statements within it complete, so there is still value in allowing the service to reorder statements within a changeset.
> 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]