Originally we had the ability to create sub-DB instances under certain level path with the original leveldb implementation. We scratched that in favour of full level paths available to all function calls.
However in some circumstances, it should be possible to create a sub-DB that has a levelpath as a prefix for all operations. This allows us to create a DB instance that can be injected into EFS, and so Polykey's DB instances will be unified, rather than having one for the vaults domain and one for the rest of PK. This will be more efficient as it will share crypto routines and other bookkeeping overhead.
There are some challenges. By putting a prefix, we sort of prevent any operations occurring outside of that level path. However the root DB could still perform operations on key values under that level path.
Transactions should operate the same as before as if there was a sub DB instance.
It should not be recommended for the root DB to perform operations on the sub DB. This is because it is possible to create complex conflicts on the sub DB like transactions. However from a lifecycle point of view, the sub DB has a more basic lifecycle, such as destruction would jsut be clearing things. The root DB lifecycle would affect all sub DBs though. We may wish to add a force option so that by default root DB lifecycle would throw an exception if sub-DBs exist.
Specification
Originally we had the ability to create sub-DB instances under certain level path with the original leveldb implementation. We scratched that in favour of full level paths available to all function calls.
However in some circumstances, it should be possible to create a sub-DB that has a levelpath as a prefix for all operations. This allows us to create a DB instance that can be injected into EFS, and so Polykey's DB instances will be unified, rather than having one for the vaults domain and one for the rest of PK. This will be more efficient as it will share crypto routines and other bookkeeping overhead.
There are some challenges. By putting a prefix, we sort of prevent any operations occurring outside of that level path. However the root DB could still perform operations on key values under that level path.
Transactions should operate the same as before as if there was a sub DB instance.
It should not be recommended for the root DB to perform operations on the sub DB. This is because it is possible to create complex conflicts on the sub DB like transactions. However from a lifecycle point of view, the sub DB has a more basic lifecycle, such as destruction would jsut be clearing things. The root DB lifecycle would affect all sub DBs though. We may wish to add a
forceoption so that by default root DB lifecycle would throw an exception if sub-DBs exist.Additional context
56 - beware of any transactional operations
Tasks