In bulk API store(), a node's `parent` field may only be `null` for root nodes

[enikao]

When sending a node to bulk API store operation, which values are valid for the field parent in node serialization?

(We ignore that parent of a partition is always null.)

Option A: Symmetric with its parent's containment/annotation

For each node, we MUST also send its parent node. The parent's containments/annotations MUST mention the child node's id,
and the child MUST mention the parent's node id.

Pro:

• Perfect symmetry

Con:

• We can never send subtrees, as we always need to (transitively) also send all parents. For each parent, we must also send all children (to keep symmetry). So we always must send the whole partition.

Option B: Can always be null

Pro:

• We can build the model tree from containments/annotations info, so parent field is not needed
• Less chances of inconsistent chunks

Con:

• Less chance of detecting issues

Option C: Symmetric with its parent IF parent is also part of the request, null otherwise

Pro:

• Better chance of detecting issues

Con:

• Relatively complex criteria

Option D: Symmetric with its parent, interpret null as "delete node"

Pro:

• Allows deletion without new command
• In line with bulk API idea "I send you how the model should be"

Con:

• Implicit deletion, and deletion is a dangerous operation (as it might be recursive)
• Relatively complex criteria

Option E: Symmetric with its parent, also check parent, also check the repository for parent node

For each node, we CAN also send its parent node. If the parent is not part of the same request, the parent MUST already exist in the repository.
The parent's containments/annotations MUST mention the child node's id, and the child MUST mention the parent's node id.

Pro:

• Perfect symmetry
• No need to send unchanged (parent) nodes

Con:

• ?

[joswarmer]

Option E: Symmetric with its parent
Like option A, but we also check with a parent that is already in the repository.

Since we have parent in the serialization, the value of parent should always be consistent with the fact that the node is in a containment/annotation of that specific parent. Whether that parent is in the request or already in the repository. This option isn't mentioned yet, so this is a new option.

Ad option B: it makes no sense to require a parent property in the serialisation and then completely ignore its value. If we allow this I see no reason for the parent property in the serialization anymore.

[enikao]

Option E: Symmetric with its parent Like option A, but we also check with a parent that is already in the repository.

Added to description above

[enikao]

Ad option B: it makes no sense to require a parent property in the serialisation and then completely ignore its value. If we allow this I see no reason for the parent property in the serialization anymore.

In #55, we decided to mention the parent, even though it's redundant. It allows to find my parent even if I haven't requested it yet.

[joswarmer]

Ad option B: it makes no sense to require a parent property in the serialisation and then completely ignore its value. If we allow this I see no reason for the parent property in the serialization anymore.

In #55, we decided to mention the parent, even though it's redundant. It allows to find my parent even if I haven't requested it yet.

Therefore the parent should be consistent with the containment/annotation in the parent.

[enikao]

We've decided in #223 that parent might only be null for root nodes. In any other case, we MUST send the real parent node id (Option A).