Fork me on GitHub
#datomic
<
2020-05-28
>
tatut07:05:12

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)

fmnoise08:05:13

nope, it's not safe, you should have some app level identities

tatut08:05:28

ok, thanks

Lone Ranger12:05:14

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?

arohner12:05:22

datomic.api is only available for peers (on-prem), not cloud

Lone Ranger13:05:50

Thank you! 🙇

arohner13:05:07

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?

marshall13:05:41

you can do it either way

arohner14:05:01

db.error/entity-attr Entity -9223301668109487396 missing attributes [email protected] of spec $foo

arohner14:05:02

Is that an error in the way I defined the spec, or a bug in datomic?

ghadi14:05:28

please provide your inputs

ghadi14:05:38

both the d/transact args and the specs

arohner08:05:33

{: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]}}}]})

favila11:05:04

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

favila11:05:15

I don’t think composite attr updates flow back into the non-composite attrs

favila11:05:24

Only the other way around

arohner12:05:04

The official docs seem to do that:

[{:reg/course [:course/id "BIO-101"]
  :reg/semester [:semester/year+season [2018 :fall]]
  :reg/student [:student/email ""]}] 

arohner12:05:20

Isn’t that year+season a write to a composite tuple by passing in a vector?

favila12:05:02

no that is a lookup ref

favila12:05:42

: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]

favila12:05:56

(or fail if no such entity)

favila12:05:37

I think your cryptic, horrible error message is :db/ensure complaining that the source tuples are not written

favila12:05:04

i.e. that ::money/currency ::money/value were not asserted

arohner12:05:55

it works when I assert money/currency and money/value, thanks

favila12:05:16

Note this in the docs:

favila12:05:18

> Composite attributes are entirely managed by Datomic–you never assert or retract them yourself. Whenever you assert or retract any attribute that is part of a composite, Datomic will automatically populate the composite value.

👍 4
favila12:05:15

so in your example you were looking at in the docs, the earlier transaction `

{:semester/year 2018
  :semester/season :fall}
is what wrote [:semester/year+season [2018 :fall]]