datomic 2024-01-07 | Slack Archive

itaied10:01:35

hey guys, I've just read and tried the datomic tutorial and starter kit (https://github.com/Datomic/ion-starter/tree/master) I was wondering how to manage schema changes ("migrations") and ensure they happen only once (does it even matters?). In the starter kit, there's a function called data-loaded? that ensures the schema has been transacted only once. This function tracks a specific change of the schema, and I'm looking for something more generic (like SQL migration tools). I was thinking about using it as a tx function to avoid read race condition, but I'm not sure about it. What do you guys think? how do you handle changes to the schema (preferably as part of a CI)

(defn- data-loaded?
  [db]
  (has-ident? db :inv/sku))

cch103:01:35

I wrote this to handle migrations for our Datomic Cloud app: https://github.com/recbus/caribou

cch103:01:20

There is also a nice tool for Datomic On-Prem called conformity.

itaied05:01:18

we are planning on using datomic cloud, so the conformity lib is not good for us Ill take a look at the first one you sent me isn't it weird that there's no a go-to popular lib to handle these stuff? how do people manage their schema changes?

itaied05:01:40

@U0698L2BU how do i install it? I couldn't find it on clojars

danieroux13:01:33

@U057T406Y15 also, it does not matter. You can run the same schema tx more than once. And if the schema Just Accrues Changes, then migration is a non-event. Does that make sense?

cch113:01:51

(except for time-to-complete, which can be painful in some contexts).

cch113:01:29

@U057T406Y15, it’s available as a git dependency. And the README provides some brief instructions. I’m hoping to improve the documentation this winter.

itaied15:01:54

@U9E8C7QRJ it does create an empty tx tho, I'm not sure I fully understand the consequences.. @U0698L2BU Thanks I'll dig into that

cch100:01:30

@U057T406Y15 - the “consequences” of an empty transaction are, arguably, exactly the semantics one wants. It’s an indication that, while an effort was made to refresh data, there was ultimately no work to be done. Thi is a good thing and very exploitable in most scenarios. It also highlights the power of transaction metadata (which would be transacted in these “empty” txs).

itaied12:01:57

I understand, it does make sense. I'm still trying to find a way to tell the database "track this schema", which means transact when it is necessary (when it has been changed). Something doesn't feel right to transact the same schema on every CI pipeline or lambda load

cch113:01:16

WRT to CI in particular, that’s pretty much the goal of caribou.

👍 1

danieroux18:01:20

@U057T406Y15 and if you really want to avoid an empty tx, you can do a what-if-transact and do a real transact only if needed:

(defn what-if-transact
  "This will not affect the actual underlying DB"
  [conn args]
  (let [speculate-db (d/with-db conn)]
    (d/with speculate-db args)))

🙌 1

2024-01-07

Channels