Fork me on GitHub

Should a fresh connection be retrieved for every request with datomic cloud or should you cache the connection?


Hm that’s what I thought. Seeing something that looks like a memory leak though when retrieving a db connection and db value every request. Will dig into it more.


The docs for as-of ( say: > Returns the value of the database as of some time-point. What is "time-point"? A Date? Epoch millis? Datomic's t?


I'm assuming it's similar to Datomic peer: > t can be a transaction number, transaction ID, or Date.

Brian Abbott06:08:24

Is anyone from Datomic Support currently available? We are having a critical outtage at the moment.

Brian Abbott07:08:42

Please see Cognitect Support Ticket 2327 🙂 Thank you!


Hi Brian, I responded on the ticket a few hours ago.

Brian Abbott23:08:02

Thank you again so much Jaret!


@jaret my colleague @kommen submitted the issue to <mailto:[email protected]|[email protected]>. Got a request to create our zendesk accounts but got running into a XSS error when trying to set my password on


It looks like there were eventually able to create the ticket. Did they resolve the error? Was it transient or are they still having issues registering?


just tried again, still doesn’t let me assign a password


Blocked a frame with origin "" from accessing a frame with origin "". Protocols, domains, and ports must match.


What browser are you using and do you use adblock (can you try without if so to confirm)?


I have a transaction function that may return empty tx-data if certain criteria aren't met. I'd like to take a particular action only if there were datoms transacted. My understanding is that every transaction that does not fail will have at least a single datom in the tx-data of the result for the txInstant of the transaction. From what I've observed, I believe I can test whether the count of the datoms in the tx-data of the result is greater than one to determine if any additional datoms were asserted or retracted. Is this something I can rely on? Anyone have a better approach?


Assuming 1 datom transacted, you could also check if :db/txInstant is the only attr asserted in the "transaction entity". If you're not using reified transactions then this additional check is probably moot.


Yeah, I'd like to save doing an additional database lookup: I guess I could assume that the :db/id of the :db/txInstant attribute is unchanging and not do a lookup, but inspecting the datom attribute db/id in a tx-data that includes only a single datom seems redundant if I know that each non-anomalous transaction result will have at minimum a single :db/txInstant attribute. Thanks for thinking through this with me.


Is there a recommended way to hook up a java agent to a query group? Running into a strange memory issue with ions and we are having a hard time debugging with the datomic memory monitor on the provided dashboard.

Laverne Schrock20:08:12

We have one Datomic Cloud deployment running version 477-8741, and another deployment running 480-8772. On the older version we are able to make assertions about the entity with id 0, but in the newer version we cannot, due to the following error :

{:cognitect.anomalies/category :cognitect.anomalies/incorrect,
 :cognitect.anomalies/message "Boot datoms cannot be altered: <actual datom omitted, let me know if you need it>",
 :db/error :db.error/datom-cannot-be-altered}
This seems like reasonable behavior, but it doesn't seem to be documented in the changelog. Does anyone know if this is an expected change?