11.4.11 Position Inserts, allows inserts into, presumably ordered, collection of entity but limits $index query option to being a zero-based ordinal

[Hubert-Heijkers]

Section 11.4.11 Positional Inserts states that collections of entity, complex, or primitive types support inserting items at a specified location, yet only describes the use of $index for collections of complex or primitive types.

I'd like to be able to simply state that $index could be used to specify the key of the entity at the location at which the new entity ought to be inserted but realize that this wouldn't work for multi-part keys.

Section 11.4.10 Managing Members of an Ordered Collection might equally require an additional clarification. Whilst not explicitly mentioning collections of entity types, those are included as well but need no special treatment in this context as they are indexed by key.

PS #562, which is related, was closed as completed but couldn't find anything in the meeting minutes nor has the proposal be applied, seem to recall this issue came up in that discussion.

[ralfhandl]

PS #562, which is related, was closed as completed but couldn't find anything in the meeting minutes nor has the proposal be applied, seem to recall this issue came up in that discussion.

#562 has been applied, see 11.4.9.4 Update a Collection Property.

The cloned GitHub issue #562 points to the original Jira issue ODATA-1437, which in turn links to pull request #136 applying the changes. I've now directly cross-linked #562 and #136.

[ralfhandl]

I'd like to be able to simply state that $index could be used to specify the key of the entity at the location at which the new entity ought to be inserted but realize that this wouldn't work for multi-part keys.

A new entity can be inserted into a collection of entities by sending a POST request to the collection. This allows inserting fully keyed entities as well as entities where (part of) the key is server-generated.

The server can then decide which index position this new entity will have.

If the new index needs to be defined by the client, this could be done by annotating the new entity with a custom annotation such as @Custom.IndexDirectlyAfter: <list or map of key values>.

[Hubert-Heijkers]

I'd like to be able to simply state that $index could be used to specify the key of the entity at the location at which the new entity ought to be inserted but realize that this wouldn't work for multi-part keys.

A new entity can be inserted into a collection of entities by sending a POST request to the collection. This allows inserting fully keyed entities as well as entities where (part of) the key is server-generated.

The server can then decide which index position this new entity will have.

If the new index needs to be defined by the client, this could be done by annotating the new entity with a custom annotation such as @Custom.IndexDirectlyAfter: <list or map of key values>.

I wasn't suggesting to change how one adds an entity, nor would I like to change what goes into the body of the POST request (especially if I'm getting that from somewhere else - read: I'd therefore also prefer not to have to insert any [custom] annotations INTO the body either).

Reading the first sentence of 11.4.11, which explicitly also refers to/includes collections of entity types, stems me hopeful. Reading what follows in 11.4.11 leaves me wondering what to how I come up with that zero-based ordinal in case of a collection of entity type.
In such collection, in combination with optimistic concurrency, I could probably figure out the ordinal of an entity and then use that on the subsequent POST request, would you agree @ralfhandl?

So why not allow specifying the key or list/map of key values as the value for $index in case we are dealing with an ordered collection of entity?

[ralfhandl]

why not allow specifying the key or list/map of key values as the value for $index in case we are dealing with an ordered collection of entity?

A non-negative integer value of $index is where you expect the inserted member to be located at directly after the insert.

With a list/map of key values this is not the case, you expect it to be right after the numeric index of the entity whose key values you specified. Hence I'd prefer a new and precise name for this new feature.