[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (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:all-tabpanel ]
Michael Pizzo updated ODATA-157:
--------------------------------
Proposal:
Clients SHOULD specify a content-id header for each request within a changeset.
[MikePizzo: it might be simpler if we just always require the client to specify a content-id; it isn't hard to do and reduces the cases we have to define).
Services MUST return the specified content-id (if any) in the response.
Services MAY process requests within a changeset in any order.
Services MAY return results within the changeset in any order if and only if the client specified a content-id for each request part.
[MikePizzo: I would change the above rule to not depend on whether the client specifies a content-id for each request part]
Services MUST return a response for each request, or a single error for the changeset.
was:
Clients SHOULD specify a content-id header for each request within a changeset.
Services MUST return the specified content-id (if any) in the response.
Services MAY process requests within a changeset in any order.
Services MAY return results within the changeset in any order if and only if the client specified a content-id for each request part.
Services MUST return a response for each request, or a single error for the changeset.
Changesets represent an atomic unit of change. The entire changeset may succeed or fail. At the end of applying the changeset the service must be in a consistent state that preserves integrity constraints (or the atomic request fails).
Individual statements within a changeset may not preserve integrity. For example, there may be a statement to remove a link from an orderdetail to a product, and another statement to add a link from the same orderdetail to a different product. These statements may come in any order.
The constraint that every orderdetail must have exactly one related product may be temporarily violated but the end result is consistent and preserves integrity of the set.
In processing these requests, the service may reorder the individual requests in order to reduce the likelihood of an integrity constraint violation; for example, it may do all deletes first, followed by inserts, followed by updates. Allowing the service to return results in the order they are executed, rather than the order they are received, allows the service to stream results rather than buffer an entire changeset worth of results.
Separate statements within a batch do not allow reordering by the service as they are each separate operations and must leave the database in a consistent state that does not violate constraints. Thus we can mandate that they are returned in order.
Saying that services may return results in any order if and only if the client specifies a content-id means that the service needs to have all of the logic to buffer and reorder results in case the client doesn't specify content-id. Instead, we should simply say that the client must specify content-id if it cares about processing results; if it is simply going to generate the request, fire, and forget then it technically doesn't need the content-id, but if it cares about processing results it is not onerous to provide the content id.
By the same token, I would also be fine saying that the client must specify a content-id on each request within a changeset, and that services must return this content-id, in order to keep things simple.
> 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]