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-616) Allow POST to collections of complex types, and DELETE with $filter


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

Michael Pizzo edited comment on ODATA-616 at 6/8/15 8:56 PM:
-------------------------------------------------------------

Assume this would also apply to collections of primitives.

The reason we have historically not supported update/delete of a member within a collection of primitive or complex types is because there is no identifier for the individual member. 

What people generally want to do is use the index to update/delete the member. We have not defined support for this in the general case, as the index may not be stable (in the case of unordered collections or in the presence of other adds/deletes). However, for the (common) case where the collection is ordered, the client can rely on etag values for the entity to guarantee that no additional members have been added or deleted.

So, if we added an annotation to collections to specify whether or not their order was stable we could define an interoperable mechanism for using (0-based? 1-based) indexes to reference members of a collection of primitive/complex types (using ()? []? key-as-segment?) (presumably supported for GET/PUT/PATCH/DELETE to that member).


was (Author: mikep):
Assume this would also apply to collections of primitives.

The reason we have historically not supported update/delete of a member within a collection of primitive or complex types is because there is no identifier for the individual member. 

What people generally want to do is use the index to update/delete the member. We have not defined support for this in the general case, as the index may not be stable (in the case of unordered collections or in the presence of other adds/deletes). However, for the (common) case where the collection is ordered, the client can rely on etag values for the entity to guarantee that no additional members have been added or deleted.

So, if we added an annotation to collections to specify whether or not their order was stable we could define an interoperable mechanism for using (0-based? 1-based) indexes to reference members of a collection of primitive/complex types (presumably supported for GET/PUT/PATCH/DELETE to that member).

> Allow POST to collections of complex types, and DELETE with $filter
> -------------------------------------------------------------------
>
>                 Key: ODATA-616
>                 URL: https://issues.oasis-open.org/browse/ODATA-616
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol, OData URL Conventions
>    Affects Versions: V4.0_OS
>            Reporter: Ralf Handl
>              Labels: Usability
>             Fix For: V4.1_WD01
>
>
> This is a natural extension that does not require indexing into collections



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