@quoll Is my understanding correct that wrap-graph is meant to basically temporarily defer transactions to an in-memory graph and unwrap-graph is meant to finalise these in-memory transactions?
It’s more than that
It’s for 2 things:
• Implementing with to create a hybrid of committed storage and in-memory storage.
• A new place for transactions to be sent to, with responses being immediate, and then a thread can be launched in the background to merge the committed and in-memory storage into permanent committed data.
The first one is done, but not tested. The second has a way to go
My use case is this: I have a large in-memory graph which is computed anew when the system boots. However, I need persisted storage for user preferences etc., so in essence I need to merge the large in-memory graph with the smaller persisted graph of user-generated content and make sure that any transactions made once the system is up and running all go into the persisted graph rather than the in-memory graph. So really it isn’t a big issue, I guess I can just keep the two graphs separate. It would just be nice to be able to only consider a single graph and have this behaviour. Not sure if it possible with the wrapgraph.ns as-is.
Maybe it could be accomplished by doing this?
(->GraphWrapper on-disk-graph mem/empty-graph
large-in-memory-graph (get-logging)))Hmm, GraphWrapper intentionally keeps transactions in an in-memory graph, regardless of what type of persisted graph you’re wrapping. In theory, I ought to be able to create a variation that allows you to set both the persisted graph (in-memory, in this case), and the one for transactions (on disk). It just never occurred to me that such a thing might be needed