datalevin

Max 2026-06-27T14:51:54.892759Z

If datalevin's databases are mutable references not static values, what's the purpose of :db-before and :db-after in transaction reports? Shouldn't they be equivalent?

Huahai 2026-06-27T15:16:55.979759Z

they allow people to compare the db state changes. Very useful to verify upsert, replacement, component retraction, etc. And critical in tx-data->simulated-report, otherwise, the simulation is useless.

Huahai 2026-06-27T15:17:22.667849Z

they are not equivalent

Max 2026-06-27T15:17:27.809289Z

So if you query db-before, do you only see datoms that were available prior to the txn?

Huahai 2026-06-27T15:18:22.588709Z

that's not the difference, The difference is the specific state change that you can verify.

Max 2026-06-27T15:18:37.698799Z

how do you verify it?

Huahai 2026-06-27T15:20:39.446209Z

same query or pull, different result, e.g.

(let [report (d/transact! conn [{:db/id 101
                                   :account/status :closed}])]
    {:before (d/pull (:db-before report) [:account/status] 101)
     :after  (d/pull (:db-after report)  [:account/status] 101)
     :datoms (:tx-data report)})
allow you to verify that status changed from :open to :closed,

Max 2026-06-27T15:22:35.420429Z

Ok, so querying a db-before can access any datoms that were present in the database prior to the beginning of the txn? Or can it only reliably access the prior state of datoms that were changed in the txn?

Huahai 2026-06-27T15:23:10.415549Z

yes, it only covers the datoms that touched in the txn

Max 2026-06-27T15:24:21.777059Z

aha, that's an interesting constraint that should be mentioned in the book. You can imagine someone querying another attr on an entity affected in a txn and being surprised that it changed out from under them

Huahai 2026-06-27T15:25:05.446579Z

will do