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-387) Replace (at least) the second example in Section 13 of the CSDL document (public comment c201305e00002)

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

Ralf Handl updated ODATA-387:

Provide an example that shows BOTH the use of a navigation property binding (for the case where the target is known) and that does not (for the case where the target is not known). Clarify that the navigation property binding is used where this information is available, not excluded if it is "implicit". 

Example text: 

In the following example there are separate entity sets for standard customers and preferred customers, but only one entity set for orders. The entity sets for standard customers and preferred customers both have navigation property bindings to the orders entity set, but the orders entity set does not have a navigation property binding for the Customer navigation property, since it could lead to either set of customers:

<EntityContainer Name="Sales" IsDefaultContainer="true"> 
  <EntitySet Name="StandardCustomers" EntityType="Self.Customer"> 
    <NavigationPropertyBinding Path="Orders" EntitySet="Orders"/> 
  <EntitySet Name="PreferredCustomer" EntityType="Self.Customer"> 
    <NavigationPropertyBinding Path="Orders" EntitySet="Orders "/> 
   <EntitySet Name="Orders" EntityType="Self.Order"/> 

Also state in definition of Partner attribute for edm:NavigationProperty that:
- if the identified partner navigation property is single-valued, it will lead back to the source entity from all related entities
- if the identified partner navigation property is multi-valued, the source entity will be part of that collection
- if no partner navigation property is specified, no assumptions can be made as to whether one of the navigation properties on the target type will lead back to the source entity.

  was:Explicitly state that V4 allows more flexibility than V3 and that the DiscontinuedProducts example can be solved differently in V4. It is legal NOT to state a navigation property binding, so an order item MAY point to an entity of the correct type in any set, and there's no requirement for entities NOT to change their set, as long as they live in at most one set (note: may not be member of any set) and are uniquely identified within their current set by their key.

    Environment: [Proposed]

Adapted proposal to use Mike's example

> Replace (at least) the second example in Section 13 of the CSDL document (public comment c201305e00002)
> -------------------------------------------------------------------------------------------------------
>                 Key: ODATA-387
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-387
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Stefan Drees
>            Priority: Minor
>             Fix For: V4.0_CSD02
> The public comment [c201305e00002](https://lists.oasis-open.org/archives/odata-comment/201305/msg00002.html) with title "DiscontinuedProducts is a really bad example'" challenges the second example given in the document revision of CSDL that participates in CSD01 public review as "really bad at best"(citation).
> The example (as copied from the html version of the CSD01 PR document) for "Other entity models may expose multiple entity sets per type. For instance, an entity model may have the following entity sets:" goes like this:
> """
> <EntitySet Name="Products" EntityType="Self.Product"/>
> <EntitySet Name="DiscontinuedProducts" EntityType="Self.Product"/>
> """ 
> The original poster (OP) further states w.r.t the current example, that: "It means a Product instance changes its entity set when it becomes discontinued, and that means any existing relationships to it become illegal.  There are still Order instances that need to refer to it (assuming it was ordered before it was discontinued), but now they can't intuitively refer to it because it doesn't exist in the Products entity set anymore -- it moved to the DiscontinuedProducts entity set.  An Order entity would need to a DiscontinuedProduct navigation property in order to refer to it.
> He then points to an example by Mike Pizzo of exposing a single type across multiple entity sets as provided to the odata.org mailing list [1](http://mailinglist.odata.org/scripts/wa-ODATA.exe?A2=ODATA;bc4700a0.1302).  The commenter thinks, that "Including this example would not only provide a correct example, but it would also demonstrate a situation where the new NavigationPropertyBinding element of EntitySet is required in order to disambiguate the target entity sets of navigation properties."(citation)
> For further details and possibly additional issues raised by the comment cf. [c201305e00002](https://lists.oasis-open.org/archives/odata-comment/201305/msg00002.html)

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]