asami

Jakub Holý (HolyJak) 2023-02-02T18:22:37.909179Z

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

quoll 2023-02-02T18:28:28.441519Z

Because by calling transact you get a new transaction time on the graph

quoll 2023-02-02T18:28:46.096079Z

I did wonder about this, but I figured it’s like calling touch on a file

quoll 2023-02-02T18:29:02.532419Z

the sha256 might not change, but the timestamp does

quoll 2023-02-02T18:29:54.581629Z

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

👍 1
Jakub Holý (HolyJak) 2023-02-02T19:04:36.524049Z

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?

quoll 2023-02-02T19:05:27.461969Z

That already happens. Let me look

quoll 2023-02-02T19:13:11.154289Z

@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

quoll 2023-02-02T19:13:32.217609Z

If there is anything in that field, then it that’s the changes that occurred

quoll 2023-02-02T19:13:54.162689Z

That’s how it’s SUPPOSED to work anyway 😬

Jakub Holý (HolyJak) 2023-02-02T19:13:56.139549Z

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

quoll 2023-02-02T19:14:05.021219Z

hmmm

quoll 2023-02-02T19:14:10.863239Z

give me another second

Jakub Holý (HolyJak) 2023-02-02T19:14:26.154909Z

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) 2023-02-02T19:14:42.101239Z

(I only looked at the duable impl)

quoll 2023-02-02T19:15:29.521749Z

That’s right

quoll 2023-02-02T19:15:59.705279Z

With the in-memory version anyway (and I think it’s the same), add an extra arg tot he call to graph-transact: (volatile! [[] [] {}])

quoll 2023-02-02T19:16:46.591509Z

Oh, wait… you need to get it back

✅ 1
quoll 2023-02-02T19:16:48.702049Z

hang on

Jakub Holý (HolyJak) 2023-02-02T19:16:54.962169Z

Ah, I saw the generated argument but did not know what it was/did

quoll 2023-02-02T19:18:38.412879Z

Yes, I was already passing around TOO much data, and this was added in later

Jakub Holý (HolyJak) 2023-02-02T19:18:41.830509Z

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

quoll 2023-02-02T19:18:56.874109Z

So I just added a volatile, and the transaction fills it in

quoll 2023-02-02T19:20:07.504829Z

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

quoll 2023-02-02T19:23:46.534649Z

Ah, nice… the durable store uses the same function. Whew!

quoll 2023-02-02T20:28:03.864899Z

Past Paula often surprises me how she did the right thing when I wasn’t expecting her to. I am often grateful to her

😹 1
🤘 1
quoll 2023-02-02T19:25:43.330629Z

so (seq (:tx-data @(transact conn …))) should be truthy for changes

quoll 2023-02-02T19:26:50.987059Z

But yes, give it your own volatile and it will fill it with everything that was asserted and retracted

quoll 2023-02-02T19:32:55.023919Z

I don’t seem to have tests. I need to add that