[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=31910#action_31910 ]
Michael Pizzo commented on ODATA-157:
-------------------------------------
Agreed that the client should always specify Content-ID within the changeset and should rely on the returned Content-ID to correlate responses. We should not add the additional burden on the client or server to correlate requests within a changeset by sequence. This allows the server to re-order related items within a changeset in order to execute the set of items that make up a single transaction, and still stream results.
The server has no transactional need to re-order the items within the batch; each separate item within a batch is done as a separate atomic transaction. If these are executed asynchronously they should return 202 Accepted, rather than rely on the server to serialize if and how the individual requests are completed, blocking until a next result is available or returning a partial batch.
> 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]