Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-03-10

Channels

#datomic
<
2021-03-10
>
mafcocinco01:03:08

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.

em04:03:04

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.

mafcocinco04:03:55

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?

mafcocinco04:03:42

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.

thumbnail12:03:13

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

jaret13:03:55

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

3
thumbnail13:03:30

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

jaret13:03:44

The Presto CLI we had to settle on is 348

jaret13:03:54

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

jaret13:03:52

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

thumbnail13:03:04

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

thumbnail20:03:45

Happy to report a upgrade fixed these problems. Thanks!