@quoll I have noticed that d/transact (with :update-fn leveraging graph/graph-transact ) returns a new db version even if no changes have been transacted. This is not ideal because it makes it harder to verify whether any changes were performed or not. I can always use a volatile! and set it within the update-fn to communicate this but it feels “dirty”. What was the reason for updating the version even if the graph is the very same instance?
Because by calling transact you get a new transaction time on the graph
I did wonder about this, but I figured it’s like calling touch on a file
the sha256 might not change, but the timestamp does
It was an explicit choice though. It’s possible to change this, but until now I have been comfortable with the reasoning I went with
Ok! Is there some simple way to detect whether anything has changed? Or is vreset!-ing a volatile insude the update-fn to communicate that to the caller the best way?
That already happens. Let me look
@holyjak OK… I just looked at all the code for the in-memory implementation (I did not look at the tests yet, nor did I check the implementation of the durable store).
If nothing was changed, then the result of a transaction should include a tx-data field that is an empty seq
If there is anything in that field, then it that’s the changes that occurred
That’s how it’s SUPPOSED to work anyway 😬
I thought about that but with a custom update-fn, no tx-data is returned.
hmmm
give me another second
I remember from your impl that you use volatile inside the update-fn to communicate back the stuff that is then returned in tx-data
(I only looked at the duable impl)
That’s right
With the in-memory version anyway (and I think it’s the same), add an extra arg tot he call to graph-transact: (volatile! [[] [] {}])
Oh, wait… you need to get it back
hang on
Ah, I saw the generated argument but did not know what it was/did
Yes, I was already passing around TOO much data, and this was added in later
Well, using this is an improvement - instead of modifying my own volatile!, I can use this one and be 100% sure that if it is empty then no change was done
So I just added a volatile, and the transaction fills it in
If you look at the in-memory storage, you can see that it adds to retracts and asserts whenever anything is added or removed. Then these go into the volatile at the end:
https://github.com/quoll/asami/blob/1194563a030dc1adb596bcb788e4ee798bb39e82/src/asami/common_index.cljc#L24-L41
Ah, nice… the durable store uses the same function. Whew!
Past Paula often surprises me how she did the right thing when I wasn’t expecting her to. I am often grateful to her
so (seq (:tx-data @(transact conn …))) should be truthy for changes
But yes, give it your own volatile and it will fill it with everything that was asserted and retracted
I don’t seem to have tests. I need to add that