This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-28
Channels
- # babashka (29)
- # beginners (179)
- # bristol-clojurians (1)
- # calva (9)
- # chlorine-clover (47)
- # cider (57)
- # clj-kondo (1)
- # cljs-dev (13)
- # clojure (241)
- # clojure-europe (9)
- # clojure-nl (4)
- # clojure-norway (88)
- # clojure-spec (4)
- # clojure-uk (15)
- # clojurescript (211)
- # clojutre (1)
- # community-development (8)
- # core-async (1)
- # datomic (31)
- # figwheel-main (33)
- # fulcro (29)
- # ghostwheel (6)
- # graalvm (11)
- # graphql (12)
- # instaparse (4)
- # jobs (1)
- # jobs-discuss (17)
- # leiningen (7)
- # malli (6)
- # meander (38)
- # off-topic (208)
- # onyx (6)
- # re-frame (23)
- # reagent (8)
- # shadow-cljs (61)
- # spacemacs (10)
- # sql (5)
- # yada (5)
If I migrate data serialized from another db instance to a new one, is it safe to transact them with the original :db/id
numbers? or do I need to make them strings and do some mappings… (in datomic cloud)
FINALLY got company to green light datomic and now that I'm using the real thing (vs free/datascript), I don't really have a good mental model for why I would choose the client API (`datomic.client.api`) vs datomic.api
. Is this a philosophical thing or are they different tools for different mediums? Or are they just different tools in different bags that could be used for similar tasks?
ahhh perfect
Thank you! 🙇
How do queries with composite tuples work? Can you ‘destructure’ and query via the tuple, or is going through the source attributes the only way?
@arohner https://docs.datomic.com/cloud/query/query-data-reference.html#untuple yes 🙂
db.error/entity-attr Entity -9223301668109487396 missing attributes clojure.lang.LazySeq@51fbd656 of spec $foo
{:db/ident ::money/currency :db/valueType :db.type/keyword :db/cardinality :db.cardinality/one} {:db/ident ::money/value :db/valueType :db.type/bigdec :db/cardinality :db.cardinality/one}{:db/ident ::money/money :db/valueType :db.type/tuple :db/tupleAttrs [::money/currency ::money/value] :db/cardinality :db.cardinality/one}{:db/ident ::accounts/tx-item :db.entity/attrs [::accounts/account-id ::money/money]} (d/transact conn {:tx-data [#:griffin.proc.accounts{:tx-id #uuid “ddcc9e32-c65e-5024-b82a-be3a3324d496”, :tx-items #{{:db/ensure :griffin.proc.accounts/tx-item, :griffin.proc.accounts/account-id #uuid “35db4a29-0bcc-5614-b27e-920c5f31a3a4", :griffin.money/money [:GBP 0.00M]} {:db/ensure :griffin.proc.accounts/tx-item, :griffin.proc.accounts/account-id #uuid “c0d87137-2c39-520c-ad6d-aa529843c38f”, :griffin.money/money [:GBP 0.00M]}}}]})
Attributes with TupleAttrs are not meant to be written directly: they will be computed. This tx writes money/money, it should instead write currency and value
The official docs seem to do that:
[{:reg/course [:course/id "BIO-101"]
:reg/semester [:semester/year+season [2018 :fall]]
:reg/student [:student/email ""]}]
:reg/semester [:semester/year+season [2018 :fall]]
will desugar to [:db/add "entity-temp-id" :reg/semester [:semester/year+season [2018 :fall]]
which will resolve to an entity id with :semester/year+season
equal to [2018 :fall]
I think your cryptic, horrible error message is :db/ensure complaining that the source tuples are not written