Fork me on GitHub
Jakub Holý (HolyJak)13:09:21

This is weird, I get this error

:cognitect.anomalies/message "Attribute values not unique: :component/$order",
                            :db/error :db.error/lookup-ref-attr-not-unique
for this attribute that is NOT unique
{:db/ident :component/$order
        :db/valueType :db.type/bigdec
        :db/cardinality :db.cardinality/one}
why could that be? Or am I misunderstanding the error?


Your txdata contains or expands to something like this: [:component/$order something]. This looks like a lookup ref. It is attempting to resolve it, but it can't


Because that makes no sense


Note error is “lookup-ref-attr-not-unique”

Jakub Holý (HolyJak)14:09:36

ah, thanks a lot! I will check the tx data. That is the experience-powered art of interpreting error messages 🙂

Jakub Holý (HolyJak)14:09:00

That was it, my tx data preparation pipeline lacked (into {})

Jakub Holý (HolyJak)14:09:25

Solved: Should have been (pull ?a [*]) What is wrong with my pull here:

(d/q '[:find (pull ?a)
         :where [?a :db/ident :component/$order]]
; => IndexOutOfBoundsException at datomic.query/normalize-pull
? 🙏

César Olea14:09:34

Hello everyone! I'm currently evaluating Datomic Cloud version 884.9095. For production I have a split stack system running a primary compute group and a separate query group. My question is for staging and beta. I read somewhere that query groups could be used to separate environments: dedicate one query group for staging, one for beta, etc. I guess I can have a "beta" query group, have it use a separate database to keep the production database clean, but if I understand things correctly writes would still be processed by the primary compute group. This would be a problem if we needed to do load testing for instance. Another option would be to run separate Datomic systems: a production stack for each environment, which solves the problems above at increased maintenance and cost. How are you managing your separate environments? Thanks!


we had completely separate AWS accounts for dev / staging and production... I think that's "safest" as everything is completely isolated, haven't tried running in the same datomic


Separate datomic systems and/or aws accounts per environment is a safe bet. It allows us to upgrade the datomic version in lower environments first, make sure everything works. Then upgrade datomic in production at a later time.

César Olea17:09:50

Got it, thanks for your recommendations! I agree, safest to use separate Datomic systems and/or AWS accounts. Good to have opinions on people already running it in production. Thanks!


@U02DNF3TW3E most importantly for cost purposes -- turn off your load testing system when not running load tests 🙂

César Olea17:09:54

That's a good point @U072WS7PE it's great to be able to scale in the compute group when not in use, similar to how aurora serverless works. BTW I've enjoyed your recorded Day of Datomic videos, good stuff!