[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] [Ralf Handl: then the client MUST specify the content-id, otherwise it will not be able to interpret the response. And I really feel bad about making things harder for ALL clients just to make things easier for SOME services.] [MikePizzo: agree that it is simpler if the client always specifies content-id and correlates requests w/in a changeset to responses according to that content-id; we should not require services to have dual logic depending on whether or not content-ids are provided. I actually think correlating requests within a changeset by id is straightforward to for the client, since the changeset is atomic and all values will be returned prior to processing the next statement in the batch.] 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. [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] [Ralf Handl: then the client MUST specify the content-id, otherwise it will not be able to interpret the response. And I really feel bad about making things harder for ALL clients just to make things easier for SOME services.] Services MUST return a response for each request, or a single error for the 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]