How do you reference the current transact? Is it just adding a tempid? I’m trying to add some auditing to my db and I’ve been looking at this -> https://blog.clubhouse.io/auditing-with-reified-transactions-in-datomic-f1ea30610285. They use (d/tempid :db.part/tx), is that just creating a tempid to the transaction id in the same way that an tempid references an entity id?

https://docs.datomic.com/cloud/transactions/transaction-processing.html#reified-transactions may help

Thanks, I’ll have a read =)…

So further reading leads me to -> https://docs.datomic.com/cloud/best.html#add-facts-about-transaction-entity. It seems that "datomic.tx" is the txid for the current transaction?

yes

Great, thanks!

hey what does it mean when I get

:cognitect.anomalies/busy

I frequently do this: [?eid1 :foo/bar ?value] [?eid2 :foo/bar ?value] [(!= ?eid1 ?eid2)]. This seems like two passes on the index (I imagine). Is there a better way to do that?

I have a question around transactor function guarantees — we have a unique v attribute

{:db/ident :foo/id
 :db/valueType :db.type/string
 :db/cardinality :db.cardinality/one
 :db/unique :db.unique/value}

and we set this id in a transactor function

(fn [db eid]
  (let [n (->> (d/datoms db :avet :foo/id (str "foo" 1))
               (take-while (fn [[e a v t]]
                             (.startsWith ^String v "foo")))
               (count)
               (inc))]
    [[:db/add eid :foo/id (str "foo" n)]]))

the idea being we start at “foo1” and go from there

in testing we sometimes get

:db.error/unique-conflict Unique conflict: :foo/id, value: foo2 already held by: 17592213012316 asserted for: 17592213017846

I’m not sure how to reason about this — could be a bug in my code, or is datoms not supported inside a tx function? the index is eventually consistent?

(“foo” is actually an argument to the function for full disclosure — we prefix the auto-inc ids)

@hueyp possibly you invoke the tx function twice in the same TX on the same entity?

@favila interesting possibility — that would definitely make sense

I’m doubtful tho as the previous version of the tx function didn’t use datoms but a query of all :foo/id so would hit the same bug and has never hit it 😜

its weird because it only sometimes fails

and our tx’s are pretty consistent in datoms

oh, your d/datoms will never see "foo2"

shouldn’t it be d/seek-datoms ?

not seeing “foo2” would do it 🙂

isn't the goal here "find the highest count for this attribute plus prefix"?

you only match "foo1"

you want seek-datoms, not datoms

@robert-stuttaford checking docs 🙂

or index-range

https://docs.datomic.com/on-prem/clojure/index.html#datomic.api/seek-datoms

hah — for sure that is what we want

if you use index range, you won't have to do an attr check too

so datoms is already constrained by your supplied components?

yes, datoms is "only give me datoms matching this pattern"

perfect

seek-datoms is "start reading at the first datom that matches this pattern"

index-range is in the middle

it will not seek past the attribute

that makes a lot of sense … I was surprised when (d/datoms db :avet :foo/id "foo") returned nothing

I figured it should just start with the first one having that prefix

but didn’t question it further

be careful with seek-datoms

you need to check each index segment not just the one you want

ah — because I’ll keep going right past :foo/id as the attribute

yes

that's why index-range may be a better choice here

thanks @favila / @robert-stuttaford!

(index-range db :foo/id "foo" nil) and your take-while

if there's no assertions for foo/id at all it will just be empty, not the next attribute

I read this from the docs “The index is updated periodically in the background and contains datoms sorted in various orders.” and was like “this can’t be true for the client API” but was now questioning my life

all faith restored

@eraserhd I'm pretty sure what you are doing is a true cross join--you really do need to visit every index segment to self-join

in SQL it would be the same

optimizing it is about choosing whether to bind ?value first or ?eid1 first

huh, how would I do that?

can you rely on (index-range db attrid start end) using :avet?

it only uses avet

awesome

thanks!

@eraserhd By controlling which var is bound and which free in the previous clauses

Ah, but if you are binding two variables in the first clause, there's no way to tell Datomic which way to do it. e.g. seek on eavt, bind v, seek on avet, bind e. Hmm.

I've noticed I can't use criterium to benchmark queries, either. It seems to get stuck warming up because, I guess, Datomic periodically inserts new classes?

(oh, that could be my other components. Don't trust me on that last one.)