Clojurians Log v2

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.

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

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.

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?

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

context: https://clojurians.slack.com/archives/C03RZMDSH/p1614788315071400

@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.

The Presto CLI we had to settle on is 348

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

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

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 😅

@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

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

ok will try that. thanks