Fork me on GitHub
#datomic
<
2020-03-03
>
vlaaad15:03:26

Hi! is there a way in a transaction to reference txInstant in the same way we can reference tx with "datomic.tx" ?

souenzzo15:03:55

@vlaaad last time that i searched about it i endup with [:db/add "datomic.tx" :dummy-attribute ""] 😞

favila15:03:43

In the response :tx-data , look for an assertion of :db/txInstant where the e and the tx of the datom are the same

vlaaad15:03:18

I want to save tx instant on an entity inside transaction

favila15:03:25

I know, but this is for Enzzo

favila15:03:34

What you want you can’t do

👍 4
souenzzo16:03:11

I got it wrong . sorry.

vlaaad15:03:16

huh? I want to save tx instant on an entity

favila15:03:23

the tx instant is not available to transaction functions. I’m not sure when the implied tx instant datom assertion is added

favila15:03:44

you can add it explicitly if you know the txinstant is older than the last tx instant

favila15:03:27

consider also referencing the tx instead of copying the instant

vlaaad15:03:38

something like [:db/add "my-entity" :my-entity/created-at "datomic.txInstant"] . I just want to have a precise instant because later I might use in as-of queries

favila15:03:43

why do you want the date to match instead of transacting your own instant?

vlaaad15:03:59

Would prefer to be able to do it in single transaction, so everything is consistent

favila15:03:12

I’m talking about a single transaction

vlaaad15:03:05

because this “my-entity” is a public release version, sort of like a git tag that is then used by consumers to see data at that time

favila15:03:54

{:db/id "my-entity" :my-entity/creating-tx "datomic.tx"} is one option

favila15:03:11

but you may be mixing domain time vs time of record

Alex Miller (Clojure team)15:03:12

I don't think you can or should do this? the datom already is in a transaction that will have the txInstant when it's transacted

favila15:03:51

^^^, although ergonomically it’s not accessible as data, only metadata (i.e. can’t get at it with d/pull)

vlaaad15:03:01

yes, and this is a possibility I’m thinking about as well, but using tx id instead of date as a version will make me expose implementation details

favila15:03:41

your application would not expose tx id, it would follow the ref and expose the txInstant

favila15:03:36

Basically you want to use the TX metadata as your “domain time” for these entities

favila15:03:58

that may be warranted, but keep in mind as-of and other history features are not designed to manage domain time

favila15:03:24

so even the use case of “I have a created-at instant on an entity, I now want to use that to see what the db looked like at that moment” is suspect because it is blending those times

favila15:03:36

this may be fine if you want this domain time to have the same guarantees as your time-of-record, but in that case you should reference the TX directly (or even better use the TX on the datom directly)

vlaaad15:03:04

thanks @favila you sent me in the right direction 👍

favila15:03:01

glad to help. This is a subtilty of datomic’s history features it took me a while to internalize

favila15:03:21

like everyone else I was eager to use it to manage domain time too

favila15:03:20

interestingly Crux adds domain time as a first class concept on top of what I’m calling “record” time: https://opencrux.com/

favila15:03:07

It makes other different tradeoffs vs datomic, but if time-traveling your domain is really import it’s an option to consider

🙏 4
Daniel Mason16:03:44

Hi there, I think I may have ran into a bug on datomic-free (using version 0.9.5697)? I've made a small example of it https://github.com/danmason/datomic-close-query but essentially I was using datomic.api/query with a :timeout (in the example I set the timeout to 1ms, and it behaves in the same way) and it appeared to prevent my application from closing properly? Removing the :timeout from the query-map allowed it to exit fine.

Alex Miller (Clojure team)16:03:19

did it close if you wait 1 minute?

Alex Miller (Clojure team)16:03:38

if so, maybe (shutdown-agents) ?

Daniel Mason16:03:55

I was originally running it on something a bit longer and did include (shutdown-agents) (forgot to add that to my little example, but might be worth a try!) but it did continue running longer than a minute. I'll give that a go on this too, however, and get back to you.

Alex Miller (Clojure team)16:03:01

was just a shot in the dark :)

Daniel Mason16:03:26

Mhm 🙂 Including (shutdown-agents) , it does continue to run regardless.

magra17:03:38

Hi, when the entity got entered twice what is an idiomatic way to merge these two entities. I have entities A and B and want to change all refs that point to B to point to A and then delete (retract-entity) B. I am not a native speaker and fail to find the right keywords to goolge for this. Does anyone know a manual entry or blog post that describes that?

stijn20:03:04

when I'm executing clj -A:ion-dev "{:op :push}", I'm seeing the following error

{:command-failed "{:op :push :region us-east-1}",
 :causes
 ({:message "Unable to transform path",
   :class ExceptionInfo,
   :data
   {:home "/github/home",
    :prefix "/github/home/.gitlibs/libs",
    :resolved-coord
    {:git/url "[email protected]:my-org/my-repo",
     :sha "467d04ca6da5b43771b66eecf33aa23e768026a4",
     :deps/manifest :deps,
     :deps/root
     "/root/.gitlibs/libs/github-my-org/my-repo/467d04ca6da5b43771b66eecf33aa23e768026a4",
     :paths
     ["/root/.gitlibs/libs/github-my-org/my-repo/467d04ca6da5b43771b66eecf33aa23e768026a4/src"]}}})} 
What does this error mean?