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] (ODATA-814) Don't need TargetId in a deleted link for a to 0..1 relationship


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

Michael Pizzo updated ODATA-814:
--------------------------------

    Description: 
Note: in OData 807 we added to errata 2 that clients should not expect targetid for deleted links for to 0..1 relationships. This allows 4.01 services to omit that information:

The JSON format spec provides specific ruled about when deleted links must be rendered:

Delta responses MUST contain a deleted-link object for each deleted link that corresponds to a $expand path in the initial request, unless either of the following is true:
•	The source or target entity has been deleted 
•	The maximum cardinality of the related entity is one and there is a subsequent link object that specifies the same source and relationship.

This makes sense, because with a single valued navigation property, the source and the relationship in the required link object uniquely identify the navigation property that is having it’s value replaced.

There is a similar case of when a single-valued navigation property has it’s link removed.  In that case, the only data needed to identify the link that should be removed is the source and the relationship. 

Today, however, the spec says that the target for the link being removed must also be provided:

The deleted-link object MUST include the following properties, regardless of the specified odata.metadata value
•	odata.context – the context URL fragment MUST be #{entity-set}/$deletedLink, where {entity-set} is the entity set containing the source entity
•	source – The id of the entity from which the relationship is defined, which may be absolute or relative
•	relationship – The name of the relationship property on the parent object
•	target – The id of the related entity, which may be absolute or relative

The requirement to include the target in this scenario raises the complexity and cost for the service to do “field level” tracking as this kind of relationship is typically implemented with a foreign key column.


  was:
Note: in OData 807 we added to errata 2 that clients should not expect targetid for deleted links for to 0..1 relationships. This allows 4.1 services to omit that information:

The JSON format spec provides specific ruled about when deleted links must be rendered:

Delta responses MUST contain a deleted-link object for each deleted link that corresponds to a $expand path in the initial request, unless either of the following is true:
•	The source or target entity has been deleted 
•	The maximum cardinality of the related entity is one and there is a subsequent link object that specifies the same source and relationship.

This makes sense, because with a single valued navigation property, the source and the relationship in the required link object uniquely identify the navigation property that is having it’s value replaced.

There is a similar case of when a single-valued navigation property has it’s link removed.  In that case, the only data needed to identify the link that should be removed is the source and the relationship. 

Today, however, the spec says that the target for the link being removed must also be provided:

The deleted-link object MUST include the following properties, regardless of the specified odata.metadata value
•	odata.context – the context URL fragment MUST be #{entity-set}/$deletedLink, where {entity-set} is the entity set containing the source entity
•	source – The id of the entity from which the relationship is defined, which may be absolute or relative
•	relationship – The name of the relationship property on the parent object
•	target – The id of the related entity, which may be absolute or relative

The requirement to include the target in this scenario raises the complexity and cost for the service to do “field level” tracking as this kind of relationship is typically implemented with a foreign key column.



> Don't need TargetId in a deleted link for a to 0..1 relationship
> ----------------------------------------------------------------
>
>                 Key: ODATA-814
>                 URL: https://issues.oasis-open.org/browse/ODATA-814
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData JSON Format
>    Affects Versions: V4.0_ERRATA02
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>            Assignee: Michael Pizzo
>            Priority: Minor
>              Labels: AdoptionBlocker
>             Fix For: V4.01_WD01
>
>
> Note: in OData 807 we added to errata 2 that clients should not expect targetid for deleted links for to 0..1 relationships. This allows 4.01 services to omit that information:
> The JSON format spec provides specific ruled about when deleted links must be rendered:
> Delta responses MUST contain a deleted-link object for each deleted link that corresponds to a $expand path in the initial request, unless either of the following is true:
> •	The source or target entity has been deleted 
> •	The maximum cardinality of the related entity is one and there is a subsequent link object that specifies the same source and relationship.
> This makes sense, because with a single valued navigation property, the source and the relationship in the required link object uniquely identify the navigation property that is having it’s value replaced.
> There is a similar case of when a single-valued navigation property has it’s link removed.  In that case, the only data needed to identify the link that should be removed is the source and the relationship. 
> Today, however, the spec says that the target for the link being removed must also be provided:
> The deleted-link object MUST include the following properties, regardless of the specified odata.metadata value
> •	odata.context – the context URL fragment MUST be #{entity-set}/$deletedLink, where {entity-set} is the entity set containing the source entity
> •	source – The id of the entity from which the relationship is defined, which may be absolute or relative
> •	relationship – The name of the relationship property on the parent object
> •	target – The id of the related entity, which may be absolute or relative
> The requirement to include the target in this scenario raises the complexity and cost for the service to do “field level” tracking as this kind of relationship is typically implemented with a foreign key column.



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]