[OASIS Issue Tracker] Updated: (ODATA-177) Allow entities to be members of multiple entity sets

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Michael Pizzo updated ODATA-177:
--------------------------------

       Proposal: Close without action.   (was: Remove sentence "An entity can be a member of at most one entity set." in fourth paragraph of section 3.

Servers not able to cope with this can always restrict the models they serve to only allow one "place of residence" per entity.)
    Environment: [Proposed]

proposal was: 

"Remove sentence "An entity can be a member of at most one entity set." in fourth paragraph of section 3.

Servers not able to cope with this can always restrict the models they serve to only allow one "place of residence" per entity."

Consistent with offline discussion with Ralf and others, changing proposal to:

"Close without action"

Reasoning:

An OData entity is just a shadow of the "real thing" living somewhere in the domain model of an enterprise application. A "real thing" can cast multiple shadows, so it may show up in many OData services. Or multiple times in one service.

So I have NorthernCustomers(4711), SouthernCustomers(4712), EasternCustomers(4711), and WesternCustomers(4712). Each of four OData entities nicely belongs to one entity set. All of these sets use the same entity type, and that some of these entities have the same key value is all the indication a client will get that if it changes one of the four, another one will magically also change. We might give a hint by using the same edit link in entities with the same key, but probably that's not worth the trouble; let the infrastructure generate the canonical URL for each shadow.

Enter navigation properties: each of these customers belongs to a Country, and all Country entities live in a single Countries entity set. Which is not really a problem anymore: the Country navigation property in Customer and the Customers navigation property in Country just don't have a Partner attribute, and the latter either has no navigation property binding or binds to the Customers entity set where a third shadow of each "real thing" lives.

So the MEST problem seems to be solved and I think we can close the ticket without action; we have everything in place to model our situation.


> Allow entities to be members of multiple entity sets
> ----------------------------------------------------
>
>                 Key: ODATA-177
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-177
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_WD01
>
>
> Section 3 currently states that an entity can be a member of at most one entity set. Given the ability to model entity type hierarchies this restriction seems rather unnatural: "Manager" is a specialization of "Employee", so it seems natural to have two entity sets "Managers" and "Employees", the former being a true subset of the latter, and a new "Manager" entity, POSTed to either set, would automatically appear in both.
> Currently the only way to do that is to have an "Employees" entity set and a "Managers" function, with the drawback that the function is not advertised in the service document and thus not consumable in a hypermedia fashion.

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