OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[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=31787#action_31787 ] 

Ralf Handl commented on ODATA-157:

What exactly do we gain with this content-id referencing and response reordering within changesets?

We apparently still require correlation by ordering in the first-level batch request/response for the GET requests and the changesets themselves, so we introduce two ways of correlating request/response pairs.

We apparently don't want to force clients to use content-id correlation, or else we would raise the entry barrier for clients.

So we just introduce complexity for the servers, because they now MUST be able to cope with both ways.

> 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]