Ask questions on the official Q&A site at https://ask.datomic.com!
mafcocinco 2021-03-10T01:40:08.163600Z

Hi. Looking for some guidance one the proper way to use transactions. I’m hoping I can store a current transaction id as a way of maintaining the current version of a production db. I want to allow users of my app to make potential changes to the system against the current transaction id and then, via some “publishing process” (as yet to be defined), allow for the current transaction id to be set to the transaction id of the promoted changes. First, is this a good idea or maybe not? Second, assuming it is, what happens if multiple users create different transactions against the same transaction id and wish to commit them at the same time? I would like to read more about how facts are associated with transaction ids and how Datomic avoids collisions while only committing the facts associated with the specified transaction.

em 2021-03-10T04:19:20.163700Z

Getting a 404 on https://docs.datomic.com/release-notices.html

em 2021-03-10T04:24:04.163900Z

I'm not sure reifying all those potential changes into the actual transaction history of your shared production db makes a lot of sense, especially as you seem to be implying that these "temporary" transactions batches could change or not be "committed". The problem you are trying to solve is also a little unclear, so the solutions could be quite varied, but for starters what about just doing all "local" changes and decision making in-memory for users using with-db? You get the benefit of seeing what might happen using the full dataset, but only commit when you are satisfied/need to.

mafcocinco 2021-03-10T04:55:55.164100Z

Yes, that was my intention. Then, when it is decided that the changes are good, they can be committed by replaying the transaction outside of the with-db context?

mafcocinco 2021-03-10T04:56:42.164300Z

That is part of what I’m trying to solve. The other is when the production system actually uses the new changes, ie when it is told to refresh the transaction id that it is using.


Hi! While using Datomic Analytics (on prem 1.0.6222) we noticed :db.type/instant works as expected for attributes, except :db/txInstant . Yielding a error:

Could not serialize column 'txinstant' of type 'timestamp(3)' at position 1:2


Happy to report a upgrade fixed these problems. Thanks!

jaret 2021-03-10T13:46:55.167200Z

@jeroen.dejong This is fixed in the latest release. You need to also use an updated presto CLI.


That's awesome! I'm looking to upgrade soon either way. Will report soon.

jaret 2021-03-10T13:47:44.167700Z

The Presto CLI we had to settle on is 348

jaret 2021-03-10T13:47:54.167900Z

It's just before they changed their name to Trino.

jaret 2021-03-10T13:48:32.168100Z

Doc'd here https://docs.datomic.com/on-prem/analytics/analytics-cli.html with the link to the proper CLI

jaret 2021-03-10T13:48:52.168300Z

They changed the timestamp type out from under us 😞. Sorry about the trouble.


That should work, Thanks! > They changed the timestamp type out from under us 😅

jaret 2021-03-10T13:57:25.168700Z

@ben.hammond sorry about the frustrating start. Our hands are a bit tied on the master stack creation adding UUIDs for the nested stacks. We need to overhaul the tutorial as well, but I would like to make a recommendation for your next stack. Now that you are subscribed from Marketplace start your new system with split stacks. (launch storage and then compute). You can get the tempaltes from our https://docs.datomic.com/cloud/releases.html#current. And you can follow the split stack instructions here: https://docs.datomic.com/cloud/operation/split-stacks.html#howto

jaret 2021-03-10T14:20:17.168900Z

Thanks! I forgot to update that link to reflect the new doc org


ok will try that. thanks