Fork me on GitHub
#datomic
<
2021-08-19
>
Jakub Holý (HolyJak)13:08:55

What is a good way to refer to a past state of the DB that would survive backup+restore or something like https://github.com/fulcrologic/datomic-cloud-backup ? I suppose transaction ID changes, when replaying the transactions in a new DB but perhaps (:t (d/db conn)) remains the same, if the transactions are replayed in the same order and none is missed?

3
favila13:08:55

make your own transaction uuids

favila13:08:00

That is the only way

favila13:08:21

> perhaps `(:t (d/db conn))` remains the same, if the transactions are replayed in the same order and none is missed?

favila13:08:35

no, because the T value is used for all minted entities. If each transaction is exactly the same and issued in the same order, and you don’t hit edge cases like schema upgrades and such, maybe they will be the same, but I wouldn’t count on it

Jakub Holý (HolyJak)15:08:56

How do :db.type/ref work? I guess there are no built-in checks and I can set it to something that looks like an entity ID, even if no such entity exists (or it existed but has been retracted). Correct?

favila16:08:14

There is I think a trivial check that the T value of the entity-id does not exceed the T value of the database and the partition bits of the entity-id correspond to a partition that actually exists. However there’s no solid notion of an entity “existing” or not--it’s just a number.

favila16:08:45

I think the easiest way to enforce “the value of this ref-attr attribute is an entity obeying some expectation/interface/contract” is :db/ensure and entity specs.

Jakub Holý (HolyJak)18:08:13

I thought so. Thank you for confirmation!