Details
-
Epic
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
Multiplexing Repository
Description
Supporting multiplexing repository would have impact on various places in Oak design. There are various sub components in Oak which maintain there own storage built on top of NodeStore. For e.g. indexes are stored within NodeStore, permissions are also stored within NodeStore. Adding multiplexing support would impact such stores in following ways
The most basic application of multiplexing support is to support private and shared storage. Under this an Oak application would have a private store and a shared store. Content under certain paths would be stored under private repo while all other content is stored under shared repo
- Writing - Any content written via JCR API passes through some CommitHooks. These hooks are responsible for updating the indexes, permission store etc. Now if any path say /foo/bar gets modified the commits hooks would need to determine under which path in NodeStore should the derived data (index entries, permission etc) should be stored. For simple case of private and shared store where we have 2 sets of paths private and shared these hooks would need to be aware of that and use different path in NodeStore to store the derived content. Key point to note here that any such storage has to differentiate wether the path from which the content is being derived is a private path or shared path
- Reading - Reading requirement compliments the writing problem. While performing any JCR operation Oak might need to invoke QueryIndex, PermissionStore etc. These stores in turn would need to perform a read from there storage area within NodeStore. For multiplexing support these components would then need to be aware that there storage can exist in both shared and private stores
Terms Used
- private repo (PR) - Set of paths which are considered private to the application. Tentative example /lib,/apps
- shared repo (SR) - Set of paths which are considered shared and different versions of the application can perform read and write operations on them. Tentative example /content, /etc/workflow/instances
- PathToStoreMapper - Responsible for mapping a path to store type. For now it can just answer either PR or SR. But the concept can be generalized
Aim of this story is to prototype changes in Oak layer in a fork to asses the impact on current implementation
