In simple bulk API, we have an operation to retrieve all existing partitions. What shall that operation return?
Partitions are always nodes (#29).
Variant A: Only node ids of partitions
Return only a list of node ids.
Pro:
Con:
- There is very little we can do with only the id. We don't know the concept (or any feature), so we cannot decide whether this partition is interesting to us on a technical level. So we almost always need to query again to retrieve details about the partitions.
- New serialization format in the protocol
Variant B: Complete nodes of partitions
Return a SerializationChunk with the complete partition nodes, but no children/annotations.
Pro:
- Easy to process technically, as we know concept and features
- Can be shown as a selection to the user, as we might get a name property
Con:
- Potentially lots of information we don't need
Variant C: Complete subtrees of partitions
Effectively return the complete repository.
Pro:
Con:
- No way to reduce overhead
Decision: Variant B: return complete nodes of partitions, but no children/annotations.
In simple bulk API, we have an operation to retrieve all existing partitions. What shall that operation return?
Partitions are always nodes (#29).
Variant A: Only node ids of partitions
Return only a list of node ids.
Pro:
Con:
Variant B: Complete nodes of partitions
Return a SerializationChunk with the complete partition nodes, but no children/annotations.
Pro:
Con:
Variant C: Complete subtrees of partitions
Effectively return the complete repository.
Pro:
Con:
Decision: Variant B: return complete nodes of partitions, but no children/annotations.