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] Updated: (ODATA-414) Fix syntax for deleting links to support containment


     [ http://tools.oasis-open.org/issues/browse/ODATA-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-414:
-----------------------------

    Proposal: 
Define "the URL that represents the reference to the related entity" in a collection (used in section "11.5.6.2 Remove a Reference to an Entity" in [Protocol]) as the URL representing the relationships between two entities (defined in section "4.4 Addressing References Between Entities" in [URL]) with the id of the reference being deleted passed in the $id query option. For a to-one relationship, this is just the URL that represent the reference to the related entity (no need to add the id; in fact, it would be illegal)

Note that this id can be relative to the service root.

So, to delete a reference in a collection of related entities, you would do:

DELETE ~Customers('ALFKI')/Orders/$ref?$id=Orders(1)

Where http://myservice.svc/Orders(1) is the id of the order being removed from Customers(1).

For containment, this would look like:

DELETE ~Products(5)/OrderedIn/$ref?$id=Orders(1)/Lines(3)

Not specifying the $id would be illegal (reserved for possibly doing set operations in a future version).

To delete a reference in a to-1 relationship you omit the id:

DELETE ~Orders(1)/Customer/$ref

It is illegal to specify $id in this case, as the target identified by the path is a single entity reference, as opposed to a collection.

  was:
Define "the URL that represents the reference to the related entity" in a collection (used in section "11.5.6.2 Remove a Reference to an Entity" in [Protocol]) as the URL representing the relationships between two entities (defined in section "4.4 Addressing References Between Entities" in [URL]) with the id of the reference being deleted passed in the $id query option. For a to-one relationship, this is just the URL that represent the reference to the related entity (no need to add the id; in fact, it would be illegal)

Note that this id can be relative to the service root.

So, to delete a reference in a collection of related entities, you would do:

DELETE ~Customers('ALFKI')/Orders/$ref?$id=Orders(1)

Where http://myservice.svc/Orders(1) is the id of the order being removed from Customers(1).

For containment, this would look like:

DELETE ~Products(5)/OrderedIn/$ref?$id=Orders(1)/Lines(5)

Not specifying the $id would be illegal (reserved for possibly doing set operations in a future version).

To delete a reference in a to-1 relationship you omit the id:

DELETE ~Orders(1)/Customer/$ref

It is illegal to specify $id in this case, as the target identified by the path is a single entity reference, as opposed to a collection.


> Fix syntax for deleting links to support containment
> ----------------------------------------------------
>
>                 Key: ODATA-414
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-414
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData ABNF Construction Rules, OData Protocol , OData URL Conventions 
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.0_CSD02
>
>
> Today the syntax for deleting a link from Products(5) to the orderdetail whose id is 1  is as follows:
> DELETE ~Products(5)/OrderedIn(1)/$ref
> We did this as a shortcut to repeating the collection and id following the $ref.
> There are two problems with this syntax. First, it is semantically a bit weird in that Products(5)/OrderedIn/$ref represents the set of entity references of order details referenced by the OrderedIn nav prop of Products(5). More significantly, it doesn't work for containment scenarios, or anywhere there is no navigationpropertybinding, as the key appended to the nav property is not guaranteed to uniquely identify the related entity.
> The second problem is a manifestation of the first conceptual problem. In order to delete a relationship we need 3 pieces of information: (1) the source entity, (2) the navigation property, and (3) the id of the thing being no longer related. In a 1:1 or many:1 relationship the id of the thing being removed is implicit, but in many:many we need to specify which thing to unrelated. The current syntax assumes that this information can be derived by applying the key to the nav prop, but this alone is not sufficient.
> For collections, we could append id to the URL representing the collection of links, as in:
>    DELETE ~Products(5)/OrderedIn/$ref/OrderDetails(1)
> for non-contained OrderDetails, or:
>    DELETE ~Products(5)/OrderedIn/$ref/Orders(123)/Details(1)
> for contained OrderDetails
> For single-valued relationships we would simply omit the id, since it points to a single references (and is therefore not valid to index with an id)

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