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-292) Questions on POST, PATCH and merge/replace semantics with related entities in composite relationships


    [ http://tools.oasis-open.org/issues/browse/ODATA-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32807#action_32807 ] 

Evan Ireland commented on ODATA-292:
------------------------------------

Due to the resolution, in protocol spec (2013-03-19), we now have:

  10.4.3 Update an Entity
  ...
  The entity MUST NOT contain related entities as inline content. 

and:

  10.4.4 Upsert an Entity
  An Upsert occurs when a client sends an update request to a valid URL that identifies a single entity that does not exist. In this case the service MUST handle the request as a create entity request, or fail the request all together.

Now a "create entity request" is allowed to have inline related entities, but an "update request" is not allowed to. Is this a contradiction? How useful is upsert is it is less capable than "POST" (i.e. does not allow inline related entities)?


> Questions on POST, PATCH and merge/replace semantics with related entities in composite relationships
> -----------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-292
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-292
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Evan Ireland
>
> Some additional wording in protocol spec (2013-03-12) sections 10.4.2.2 and 10.4.2.3 might help to answer the following questions.
> Some backend systems support creation of composite objects (e.g. a "purchase order") as a composite operation requiring parent (e.g. order header) and children (e.g. order lines) to be provided together. And also, they require additions, alterations, and deletions of children to be issued as composite operations against the parent (with either merge or replace semantics, we have seen both).
> In other words, the POST request to create the parent would REQUIRE the related child entities to be included inline. And PATCH requests would need to support inline additions/updates/deletions of children.
> Q1. Are such "composite" relationships expressible with CSDL (without the use of complex types for the children, but using entities for both parent and children)? If so, then how would that affect the wording of sections 10.4.2.2 and 10.4.2.3.. (One might stipulate that the use of OnDelete="Cascade" is one quite strong indication of a composite relationship).
> Q2. Even if "composite" relationships are not expressible (except by using complex types for the children), another question may apply to section 10.4.2.3, is that whether a PATCH request is permitted to include inline values for navigation properties? (Can we "update" existing children of a parent without replacing all the parent's children, or must each child be separately updated).
> Q3. Is there any support in CSDL/protocol for composite relationships (whether children use complex or entity types) that permits "merge" (rather than "replace") semantics for child objects?
> Q4. Assuming that the answers to all the above are "No", is the server allowed to REQUIRE the use of a batch request (with a change set) when dealing with "merge"-style changes to composite relationships? (Perhaps not currently, but that might be a way forward if we were to consider a future extension).

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