Creating partitions
The repository might not know the language and therefore does not know whether a node is of a partition concept.
Therefore we need to tell the repository that a node is a partition.
Option A: Create partition node separately
Add an API: createPartition(chunk), where chunk contains one (or more) nodes which are to be stored as partition(s).
Pro
Con
- to store a partition with its children you need to have two calls: createPartition() and store(), as you cannot
have the children in the chunk, because they would be considered partitions as well.
Option B Enhance store() with a parameter indicating which nodes(s) are partitions
Pro
- New partition can be stored using one call to store()
Con
- Yet another parameter to store() making the function more complex
Option C: Implicitly create partitions
NEW Nodes without a parent in a chunk that is being stored become partitions.
Note that nodes that are already in the repository and become parent-less are still considered orphans and deleted.
Pro
Con
- Very implicit, might be to easy to create partitions by accident
Option D: Introduce a (virtual) repository node
Define a virtual node repository which acts as the root node for the repository,
with all partitions being a child of this virtual node.
This way, we can give repository as the parent for a partition node.
repository's concept would be Repository, defined in builtins language.
We would change the definition of "partition" to be a node that's owned by repository.
We could still keep special semantics of partitions (#29).
Pro:
- No new APIs
- New APIs can be added later
Con:
- Magic node (id)
- Adding partition is two-step: 1) get all partitions 2) add mine
- Relatively high chance of concurrent edit conflicts
Removing partitions
All nodes, except partitions are removed by disconnecting them from their parent.
For partition nodes this is not possible, because it doesn’t have a parent to start with.
Therefore we need to delete partition nodes in another way.
Option A: Special deletePartition(node ids) method
This removes the partition, deleting its children as well, as they become orphans.
Option B: Introduce a (virtual) repository node
Using this option a partition can be removed by calling store() with a partition node with parent = null,
or by calling store() with the repository node without the partition that should be removed in its children.
Pro/Con same as new partition Option D
Option C: Use same delete method as for other nodes
Decision: Option A (have dedicated operations) for both adding and deleting partitions.
Creating partitions
The repository might not know the language and therefore does not know whether a node is of a partition concept.
Therefore we need to tell the repository that a node is a partition.
Option A: Create partition node separately
Add an API: createPartition(chunk), where chunk contains one (or more) nodes which are to be stored as partition(s).
Pro
Con
have the children in the chunk, because they would be considered partitions as well.
Option B Enhance store() with a parameter indicating which nodes(s) are partitions
Pro
Con
Option C: Implicitly create partitions
NEW Nodes without a parent in a chunk that is being stored become partitions.
Note that nodes that are already in the repository and become parent-less are still considered orphans and deleted.
Pro
Con
Option D: Introduce a (virtual) repository node
Define a virtual node
repositorywhich acts as the root node for the repository,with all partitions being a child of this virtual node.
This way, we can give
repositoryas the parent for a partition node.repository's concept would beRepository, defined in builtins language.We would change the definition of "partition" to be a node that's owned by
repository.We could still keep special semantics of partitions (#29).
Pro:
Con:
Removing partitions
All nodes, except partitions are removed by disconnecting them from their parent.
For partition nodes this is not possible, because it doesn’t have a parent to start with.
Therefore we need to delete partition nodes in another way.
Option A: Special deletePartition(node ids) method
This removes the partition, deleting its children as well, as they become orphans.
Option B: Introduce a (virtual) repository node
Using this option a partition can be removed by calling store() with a partition node with parent = null,
or by calling store() with the repository node without the partition that should be removed in its children.
Pro/Con same as new partition Option D
Option C: Use same delete method as for other nodes
Decision: Option A (have dedicated operations) for both adding and deleting partitions.