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

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