Fork me on GitHub
#datomic
<
2018-12-07
>
Sal17:12:48

I was reading datomic’s tutorial on transacting schemas referenced here: https://docs.datomic.com/on-prem/getting-started/transact-schema.html

Sal17:12:07

But I notice in other sites or examples, there are two additional attributes specified that are not in the tutorial: :db.install/_attribute and :db/id

Sal17:12:15

Is there a reason those attributes are not presented in the tutorial?

favila17:12:26

@fuentesjr those used to be required, but now are not

favila17:12:49

the other examples you are seeing are older

Sal17:12:29

are those attributes no longer necessary, or do they simply have default values that can be overriden?

favila17:12:00

the attributes are there, you just do not have to supply them

favila17:12:45

in every case db id should be tempid in :db.user/db partition and :db.install/_attribute should be :db.user/db

favila17:12:04

they just went from requiring them for installation to inferring them

favila17:12:30

(inferred from the presence of :db/type and :db/cardinality probably)

favila17:12:07

what those did was add the new attribute to the :db.user/db entity (entity id 0) on its :db.install/attribute attribute

favila17:12:15

now that happens without you asking for it

favila17:12:33

released 2016-11-28

Sal17:12:20

so by default now all schemas are created in the db.part/user partition when those attributes are not specified?

Sal17:12:36

Also, are the entity ids unique across all of the db or are they unique only within the partition they reside?

ro617:12:20

@fuentesjr I think so. It seems like partition control in general has fallen out of common practice. I'm not sure it's even possible in Datomic Cloud. I think I read somewhere that they found it wasn't being used much and may not be "worth its weight" in the API.

ro617:12:03

Not sure about your second question.

favila17:12:34

I'm pretty sure schema is still put in the db.part/db partition

Sal17:12:05

interesting

favila17:12:22

this was mostly an interface change (you no longer need to include those assertions in your tx data) not a functionality change

favila17:12:47

if you look at the datoms added after the tx I am pretty sure they are the same

ro617:12:29

My understanding is that partitions are primarily a means of improving performance by controlling which of your datoms get indexed/cached "closer" to each other. I'm not sure if they have other functional/semantic implications.

favila17:12:57

they don't, but schema is supposed to go in db partition and I don;t think they changed that

favila17:12:49

practically speaking this just means that the entity id of attributes will be smaller

Sal17:12:29

I see. So by looking at the presense of :db.type and/or :db/cardinality, they store those datoms in db.part/db otherwise … they store them in db.part/user

benoit21:12:59

This "best practice" in the Datomic docs might need to be updated. https://docs.datomic.com/cloud/best.html#optimistic-concurrency I'm getting a java.util.concurrent.ExecutionException containing an ExceptionInfo with {:db/error :db.error/cas-failed}. Is that how to detect CAS failures now?