Fork me on GitHub
Jakub Holý (HolyJak)18:02:37

@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

👍 2
Jakub Holý (HolyJak)19:02:36

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 😬

Jakub Holý (HolyJak)19:02:56

I thought about that but with a custom update-fn, no tx-data is returned.


give me another second

Jakub Holý (HolyJak)19:02:26

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

Jakub Holý (HolyJak)19:02:42

(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

Jakub Holý (HolyJak)19:02:54

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

Jakub Holý (HolyJak)19:02:41

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:


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

😹 2

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