Fork me on GitHub
#asami
<
2022-09-19
>
simongray14:09:27

@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?

quoll14:09:55

It’s more than that

quoll14:09:57

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.

quoll14:09:16

The first one is done, but not tested. The second has a way to go

simongray14:09:30

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.

simongray14:09:20

Maybe it could be accomplished by doing this?

(->GraphWrapper on-disk-graph mem/empty-graph
                  large-in-memory-graph (get-logging)))

quoll16:09:49

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

👍 1