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] Issue Comment Edited: (ODATA-490) Clarify Referential Constraints have UpdateRule=Cascade semantics


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

Michael Pizzo edited comment on ODATA-490 at 9/25/13 5:57 AM:
--------------------------------------------------------------

I am okay with this as long as we define what happens if you specify both a bind and a dependent value in the same update payload.

Since, in the insert case, we state that the dependent values are ignored when posting to the nav prop of the primary entity, I propose we also say that the binding wins out over property values in the update case.

Also, what happens if I update the dependent value to a value that doesn't match any principle entity? I assume this is an error (or does it null out the nav prop? And what if the nav prop is not nullable?)

(As an aside, if I have a non-nullable navigation property with a referential constraint to a non-nullable principle property, MUST I apply the nullable=false attribute to my dependent property, or is it just implied? And, if I have a nullable nav prop, and the nav is null, does that imply that the dependent property is null?)

Finally, since we no longer require referential constraints to be on key (or even unique) values, what happens if the client tries to change a property on the dependent entity that is not a key property on the principle entity? Is this allowed? Does it try to find a related entity with the specified value? What if there are multiple that match? Does it try and change the value on the principle entity (and then cascade to all other related instances)?

Restricting the update to dependent properties that point to key fields feels arbitrary, but I don't think we want to allow changing dependent properties of non-key fields.

So I think our options are:
1) Make properties with referential constraints read-only
2) Make properties with referential constraints updatable, but only support referential constraints on key properties
3) Make properties with referential constraints updatable only for referential constraints point to key properties
4) Remove referential constraints from CSDL and consider adding them through a vocabulary at a later point in time.

Further, if we keep referential constraints, I would propose:
1) if a nav prop is null, then the dependent property is null
2) having a nullable nav prop implies the dependent property is nullable
    2a) Is it an error if it is declared as nullable="false"? I would say yes.
3) having a non-nullable nav prop to a non-nullable principle property implies the dependent property is nullable
   3a) MUST it be declared as nullable="false"? Or is it implied nonnullable and an error to define as nullable="true"?


      was (Author: mikep):
    I am okay with this as long as we define what happens if you specify both a bind and a dependent value in the same update payload.

Since, in the insert case, we state that the dependent values are ignored when posting to the nav prop of the primary entity, I propose we also say that the binding wins out over property values in the update case.


  
> Clarify Referential Constraints have UpdateRule=Cascade semantics
> -----------------------------------------------------------------
>
>                 Key: ODATA-490
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-490
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol 
>    Affects Versions: V4.0_CS01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.0_CSD03
>
>
> The current specification defines referential constraints that specify properties of the dependent entity must be the same as the corresponding properties of the principle entity. This is similar to a foreign key in a database which specifies that the property of a dependent row must match the (typically primary key) properties of a row in the principle table. Foreign keys in a database are defined through Referential Constraints which have a DeleteRule and an UpdateRule that specify what happens to dependent rows when the principle row is deleted or updated.
> In OData, the referential constraint implicitly includes the navigation property which enforces the uniqueness constraint required in relational databases. This allows us to define referential constraints on sets of properties that may not be unique outside of the implicitly added to 0..1 navigation property.
> In OData we also define an OnDelete rule that specifies what happens if the principle entity is deleted. However, we don't define an UpdateRule. We also don't say what happens if the client tries to update a dependent property (which would be an error if they didn't at the same time change the navigation property to point to a principle entity with the same value).
> The reasonable behavior would be for updates to the dependent properties to be ignored by the service and for updates to the referenced property in the primary entity to "cascade" to the dependent entities. This fits well with the denormalization scenario we were trying to support in allowing the referential constraint to support non-key properties. We even imply this strongly in the insert case by saying that dependent properties may be omitted and must be ignored by the service in inserting a new entity, we just are not as clear in the updating section, when we talk about omitting "key and non-updatable properties" that this includes dependent properties defined within a referential constraint.

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