What's a good way to reset the database to a known state for integration testing for an Ions app? Thinking it through I could use (do (delete-database...) (create-database ...) (transact fixtures ...)). I wondered if there was something like a (clone-database ...) or (reset-db-to tx-id) which might simplify restoring to a known state. Clearly this is somewhat at odds with providing an immutable db.

I’ve been discussing Datomic with my CTO and his biggest fear is Cognitect being a relatively small company combined with the closed source nature of Datomic. Is there any documentation that tries to address this kind of fear? Is there way to get the data out in a usable form? Can we sign a source code access agreement?

This is more specific to Datomic cloud, I guess.

Datomic sales would be the best people to talk to about all that <mailto:[email protected]|[email protected]>

Thanks @alexmiller

In some of the examples on Github, I see that the client and connections are memoized as such:

(def get-client
  (memoize #(d/client 
             {:server-type :ion
              :region "us-east-1"
              :system "stu-8"
              :query-group "stu-8"
              :endpoint ""
              :proxy-port 8182})))
(def get-http-client (memoize #(http/create {})))
(def db-name "ion-event-example")
(def get-conn (memoize #(d/connect (get-client) {:db-name db-name})))

“Datomic connections do not adhere to an acquire/use/release pattern. They are thread-safe and long lived. Connections are cached such that calling datomic.api/connect multiple times with the same database value will return the same connection object.”

https://docs.datomic.com/on-prem/clojure/index.html#datomic.api/connect

https://docs.datomic.com/cloud/client/client-api.html#connection

@okocim ^

@marshall thank you

I find myself building up a lot of tx maps with (merge m (when x {:attr-x x}) (when y {:attr-y y})) … this must be a common datomic pattern? how do y’all normally handle that idiomatically?

I guess that’s not datomic-specific, but it comes up a lot in building txes.

cond-> is your friend

@curtosis I find myself using this pattern quite a bit as well. I personally prefer using:

(cond-> {}
  x (assoc :attr-x x)
  y (assoc :attr-y y))

jinx

lol @okocim I had in the back of my head that it looked a little cond->ish

cond-> both reads better and is faster so definitely preferred

thx

ok, now a definitely datomic-related question… I’m using the “best practice” asyc tx-pipeline and sometimes I’ll get no actual elements transacted, even though the batch looks fine.

ordinarily I’d asssume they were already-asserted items, but I don’t see them in the datomic console

what should I be looking for to troubleshoot?

in on-prem, can you call a transaction function from within a transaction function? My use case was to extend a transaction function :foo/bar with a :foo/bar2, which took the results from the original :foo/bar, but added more to it

Yes, you can @csm