datomic 2024-04-02 | Slack Archive

Rodrigo Mejia Sanchez15:04:31

Hi all, my team has a deployed Datomic Cloud system. In it we have various databases, one of which we use for our staging environment where we demo new features. After a demo we’d like to be able to reset the state of the database back to what it was at the start of the demo. For this reset I am thinking I’ll delete and recreate the database (with the same name) and then seed it with our starting data. From reading up on this it seems that the delete-database function returns immediately but the cleanup of data/resources happens async. I assume this means that something like the following in a Cloud system is problematic:

(do
  (d/delete-database ...)
  (d/create-database ...))

Am I correct in assuming I shouldn’t do this? How can I know when it is safe to recreate the database? Is introducing a long enough delay in between the two function calls a fair way to go about this?

jjttjj15:04:19

You could just make the new db-name like (str "staging-" (random-uuid)) and then call d/delete-database when done

Rodrigo Mejia Sanchez15:04:49

Thanks for the suggestion, that’s valid, but I wanted to keep the name the same to avoid having to change permissions. Our staging backend has permissions only to the staging database via having access to the S3 path <datomic-bucket>/<datomic-system>/datomic/access/dbs/db/<staging-db-name>/* and this would disrupt that no?

jjttjj15:04:58

I'm not 100% positive, but I think there's some way to grant permissions to datomic-bucket>/<datomic-system>/datomic/access/dbs/db/staging-*

jjttjj15:04:00

(Sorry if this is wrong let me know. It's definitely worked for permissions for other types of aws resources I've worked with but I've never tried for datomic)

Rodrigo Mejia Sanchez15:04:15

Ah, I think maybe you’re right, it’s good to have that option, I would still like to keep the database name the same, I think we’re reliant on it being something deterministic in other places, a uuid might throw a wrench into that…

jjttjj16:04:45

Maybe you could delete/recreate the db with the same name, then do a query to make sure the db looks like a fresh db, and if not try again later. This is what first comes to mind

(defn db-ready? [db]
    (->> (d/q '[:find ?ident
                :where [?e :db/ident ?ident]]
           db)
         (every? (fn [[ident]]
                   (re-find #"^(db|fressian)\.?" (namespace ident))))))

(I just noticed those were the only idents in a fresh db for me, probably some better predicate to use)

Rodrigo Mejia Sanchez16:04:10

oh, this is a neat idea, let me give that a go, thank you @U064UGEUQ!

silian17:04:00

Time travel is one of Datomic’s central features. You can look into as-of : https://docs.datomic.com/pro/time/filters.html

2024-04-02

Channels