case-a / Whenever I stop and restart my k-gap project I have to wait for all the subyt-uplifting, syncfs-loading and traversal-harvesting to happen and populate my graphdb repo.
But also can be expanded to the more general form inside team-work:
case-b / How can I share the build up state from my earlier execution via github (or other file exchange) with team-members that can use it to kickstart their platform with the state-buildup-results I already achieved.
And all of this will hurt even more when we start having a solution for #11
For case-a we could just look into making sure the docker-instance gets an external mountpoint towards data and config that persist when the container stops & restarts.
For the more generic case-b it sounds like we should have a strategy for extract/import state from the graphdb instance in a flexible way. Allowing to (i) orderly extract & store locally at any time (ii) share / copy / transfer that with others so (iii) at start-up some interactive dialogue (or env setting) could result in selecting and preloading the inital state.
The pain is this:
But also can be expanded to the more general form inside team-work:
And all of this will hurt even more when we start having a solution for #11
For case-a we could just look into making sure the docker-instance gets an external mountpoint towards data and config that persist when the container stops & restarts.
For the more generic case-b it sounds like we should have a strategy for extract/import state from the graphdb instance in a flexible way. Allowing to (i) orderly extract & store locally at any time (ii) share / copy / transfer that with others so (iii) at start-up some interactive dialogue (or env setting) could result in selecting and preloading the inital state.