Description
Following OAK-511, I've realized that it should be simple enough to further refactor the code to provide a store(&retrieve) strategy.
The strategy could be property based (PropertyIndex), based on paths of child nodes (Property2Index), or any kind of layered structured - possibly a btree like the old PropertyIndex had.
This spans from the idea that the UUID index doesn't really need to have a new level of child nodes, it can easily keep the paths as properties.
The up side is that we could play with the store strategy until we find one that fits each implementation we have, or even have a dynamic strategy that changes over time with the amount of content the index has to store.
Attachments
Attachments
Issue Links
- is related to
-
OAK-511 Query PropertyIndex that stores the index content as nodes
- Closed