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-1010) Represent deleted entities similar to added/changed entities


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

Michael Pizzo edited comment on ODATA-1010 at 11/30/16 12:50 AM:
-----------------------------------------------------------------

Rather than add a different contextulr for deleted entities, I *think* I'd rather just say that the syntax and semantics of $deletedEntity were different between 4.0 and 4.01.

I like making id and reason annotations in deleted entities and allowing properties of the deleted entity (in particular, key fields). Then we could fall back on the same semantics we use for updated entities, where the @odata.id can be omitted if the key fields are present and the service supports odata key syntax.

If we think we might want to add additional information about the deletion, we could define a "removed" annotation and nest things like "reason" under this annotation:

    { 
      "@odata.context":"#Customers/$entityDeletion", 
      "@odata.id":"Customers('ANTON')", 
      "@odata.removed":
          {
             "reason":"deleted"
          }, 
      /* optionally properties of the deleted entity */ 
     "CustomerID": "ANTON", 
     ... 
    } 

I do worry about the complexity of having different representations for deleted entities in 4.0 versus 4.01.


was (Author: mikep):
Rather than add a different contextulr for deleted entities, I *think* I'd rather just say that the syntax and semantics of $deletedEntity were different between 4.0 and 4.01.

I like making id and reason annotations in deleted entities and allowing properties of the deleted entity (in particular, key fields). Then we could fall back on the same semantics we use for updated entities, where the @odata.id can be omitted if the key fields are present and the service supports odata key syntax.

I do worry about the complexity of having different representations for deleted entities in 4.0 versus 4.01.

> Represent deleted entities similar to added/changed entities
> ------------------------------------------------------------
>
>                 Key: ODATA-1010
>                 URL: https://issues.oasis-open.org/browse/ODATA-1010
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>            Reporter: Ralf Handl
>
> Allow representing deleted entities similar to added/changed entities
>     {
>       "@odata.context":"#Orders/$entity",
>       "@odata.id":"Orders(10643)",
>       "ShippingAddress":{
>         "Street":"23 Tsawassen Blvd.",
>         "City":"Tsawassen",
>         "Region":"BC",
>         "PostalCode":"T2F 8M4"
>       },
>     },
>     {
>       "@odata.context":"#Customers/$entityDeletion",
>       "@odata.id":"Customers('ANTON')",
>       "@odata.reason":"deleted",
>       /* optionally properties of the deleted entity */
>      "CustomerID": "ANTON",
>      ...
>     }
> This would allow using the same serialization template. And it looks more consistent :-)



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