Should updates of related resources be supported in Create?

[ralfhandl]

As described in ODATA-1450, when we create a resource we can link it to other, existing resources using @odata.id. We can also create new related resources.

This is similar to what we do with a delta patch operation and, indeed, within a delta patch operation we can create a new entity and create/update/remove related nested entities.

Should we support the same functionality when creating a single resource (i.e., using POST) that we do in a delta update?

Specifically, when we create an item using POST, should we 1) Support referencing existing items by key properties as an alternative to @odata.id? Note that, for non-contained nested resources with no navigation property binding you would have to either include the @odata.context in addition to key values or include the @odata.id. 2) Support modifying properties of related existing items?

Same question for using PUT/PATCH as an upsert – seems like at least PATCH, which already supports keyvalues and nested deltas for update, should also support the same changes as part of a create.

Imported from ODATA-1535

[ralfhandl]

Proposal:

• Support 1.
• Do not support 2.

[mikepizzo]

Proposal:

• Support 1.
• Do not support 2.

Agree we should support 1.

If we don't support 2, then there will be a difference in behavior between a create request for a single entity versus a create request for a single entity within a bulk operation.

This becomes problematic for upsert requests, since the request is interpreted as an update if the item already exists (and thus, updating related entities is supported) and is interpreted as a create if the item doesn't already exist (in which case, do we error if the payload contained an update to a related entity, where we would have succeeded with the same payload if the entity already existed?).

I propose we split the issues -- use this issue (renamed) to track the use of key values in place of @ids, and create a new issue to propose supporting updating properties of related entities in create.

[ralfhandl]

When trying to split this issue I realized that the underlying question to both parts is

• Which effect does a nested entity representation have for an insert and update request?

Ideally the answer contains "identical for insert and update".

Splitting this up into sub-questions:

1. Which effects do we allow?
2. Which nested entity representations do we allow?
3. Which nested entity representation has which effect?

Effects

• E1: Create new entity and link to it
• E2: Link to existing entity
• E3: Link to existing entity and update the now related entity

Nested entity representations

• R1: Pure entity reference

  { 
  "@context": "$metadata#$ref",
  "@id": 42
  }

• R2: Sloppy entity reference (no @context)

{ 
  "@id": 42
}

• R3: Keyed sparse entity (all key properties, only key properties)

{ 
  "KeyProp": 42
}

• R4: Keyed partial entity (all key properties, some non-key properties)

{ 
  "KeyProp": 42,
  "NonKeyOne": "valueOne",
}

• R5: Unkeyed partial entity (not all key properties, some non-key properties)

{ 
  "NonKeyOne": "valueOne",
}

• R6: Identified partial entity (entity-id, some non-key properties)

  Note: this is not an entity reference because these MUST NOT contain properties.

{ 
  "@id": 42,
  "NonKeyOne": "valueOne",
}

More representations? Feel free to add them here.

[ralfhandl]

In the above framework:

• R1 identifies
  • existing entity: E2
  • non-existing entity: error
• R2 identifies
  • existing entity: E2
  • non-existing entity: error
• R3 identifies
  • existing entity: E2
  • non-existing entity: E1, all non-key properties are filled by the server
• R4 identifies
  • existing entity: E3
  • non-existing entity: E1, omitted non-key properties are filled by the server
• R5 cannot identify existing entity
  • E1, omitted key and non-key properties are filled by the server
• R6 identifies
  • existing entity: E3
  • non-existing entity: error