[OASIS Issue Tracker] (ODATA-959) Allow path in an edm:key to also use a primitive property of a non null-able navigation property (recursively) of the entity type.

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

    [ https://issues.oasis-open.org/browse/ODATA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63904#comment-63904 ] 

Michael Pizzo commented on ODATA-959:
-------------------------------------

In general, I'm concerned about having an entity that is identified by properties that aren't part of the entity.

For example, in JSON payloads this would presumably mean that the id would always have to be written, even in minimal metadata, unless the nav properties were expanded to include at least the related ids?  Probably simpler to say the ids would always be included for such entities.

I assume other semantics would be the same; could still use key-lookup syntax (parens or key-as-segment), it would just be referencing properties not defined on the object?

I also assume, since keys are immutable, that:
1) You could only create the entity it included a link to an existing related entity containing the key value or you did a deep insert that included the related entity
2) You couldn't change the related entity containing the key value (so it would have to be single, non-nullable, and immutable)
3) The referenced property(ies) on the related entity would have to be immutable (or, if changed, would delete the entity with the dependent key)
4) Deleting the related entity would delete the entity whose key referenced a property of that entity

Other particular semantics/behaviors/restrictions we'd have to define?


> Allow path in an edm:key to also use a primitive property of a non null-able navigation property (recursively) of the entity type.
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-959
>                 URL: https://issues.oasis-open.org/browse/ODATA-959
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL
>    Affects Versions: V4.0_ERRATA03
>         Environment: Proposed
>            Reporter: Hubert Heijkers
>             Fix For: V4.01_WD01
>
>
> Currently a key can only be made up of properties that are either in the entity type directly or in a complex property recursively. It therefore explicitly excludes the use of these properties in a, non null-able, navigation property. This causes the modeler to expose the underlying data structure as he'll have to add these primitive properties to the entity directly and keeping them in sync using referential constraints.
> An example that shows this would be a situation like in graphs where nodes are connected by edges and where an edge gets particular properties associated to it. Here the edge will have to, apart from the two navigation properties representing the nodes it is connecting also two primitive properties that contain the node IDs to be able to form a key for an edge.
> Obviously many m-n relationships exist which have additional properties describing the relationship exist that would benefit.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)