For a couple of use cases (finding the current active revision, comparing revision between workspaces) it would be beneficial to have an index of all "active" revisions for a given set of contexts.
Assuming we have two context levels K and L
A
/ \
B C
/ | \
F | D
| /
E
On creating a new revision, this list could be materialized into an index table for each entity type:
entity_id
revision_id
context_k
context_l
1
A
1
B
X
1
E
Y
1
E
Y
Z
1
F
X
Z
This table could be used to performantly query for the active revision, which would require a couple of drastic joins and subqueries right now. Also it would allow query operations between contexts (workspaces) like:
"Retrieve all nodes that contain updates when moving from workspace A to workspace B"
"Retrieve all nodes that have leaves in both A and B and therefore are potential conflicts."
In this scenarios workspace A and B are not necessarily related.
Edit: To enable the latter case, we will also have to maintain a table of all parent relations.
Thinking more about this led me to the conclusion that we would anyway require an index table of ancestors and a sparse tree of "active revisions" would be a performance enhancement.
For a couple of use cases (finding the current active revision, comparing revision between workspaces) it would be beneficial to have an index of all "active" revisions for a given set of contexts.
Assuming we have two context levels
K
andL
On creating a new revision, this list could be materialized into an index table for each entity type:
This table could be used to performantly query for the active revision, which would require a couple of drastic joins and subqueries right now. Also it would allow query operations between contexts (workspaces) like:
In this scenarios workspace A and B are not necessarily related.
Edit: To enable the latter case, we will also have to maintain a table of all parent relations.