datomic 2022-06-29 | Slack Archive

JAtkins16:06:12

I guess this is a semi-periodic check - do you guys plan to adapt Datomic Console for Datomic Cloud? Or, in particular Dev Local? I’d find it quite useful it it is around.

souenzzo03:06:29

as far I understand, tap + REBL should be the final solution for "datomic cloud console"

Robert A. Randolph14:06:26

We do not have plans for Console for Datomic Cloud currently, and suggest using REBL as mentioned above.

helios16:06:19

Datomic documentation is suggesting to use :db/ident for enums (https://docs.datomic.com/on-prem/schema/schema-modeling.html#enums). However, when talking about idents (https://docs.datomic.com/on-prem/schema/identity.html#idents) it does say that > Idents should not be used as unique names or ids on ordinary domain entities. Such entity names should be implemented with a domain-specific attribute that is a unique identity. This last advice is also backed by the fact that idents are in a special cache always in memory, and that this place is permanent: if you rename an ident the old one still works, there's no retracting from this special cache. Which doesn't seem like a good place to store domain knowledge. Is this a case in which these advice were given at a different time and one is superseded? What are you folks doing in this case? An example of my use case would be to store the phase of an object, :object/phase could be :phase/entry :phase/storage :phase/exit. Should i use a ref and db/idents or a keyword?

enn16:06:02

I have always understood this advice: > Idents should not be used as unique names or ids on ordinary domain entities. as referring to non-enumerated unique identifiers. I.e., user IDs or similar, where the set of potential IDs is open. I would personally use idents for the :object/phase use case you describe.

JohnJ17:06:44

If you don't mind having application code verifying valid keywords(which you should anyway) I would go with keywords, for small pools of enumeration the performance impact won't be noticeable

favila17:06:01

A rule of thumb: if it’s something the developer creates as part of their own maintenance of the data model, you can use an ident; but idents ought not to be created by users

favila17:06:40

idents are part of the domain model not domain data

➕ 2

JohnJ18:06:42

by "you can use and ident" you imply a keyword is fine too? how helpful are the constraints of enumerated idents in the real world?

favila18:06:41

There are no ref constraints except the ones you impose yourself

favila18:06:21

Benefits of ident-entities: you can change their name (old idents continue to work even after retracted), you can add metadata (e.g. membership in an enum, a :db/doc), you get a VAET index.

JohnJ18:06:32

true, no ref constraints but the ident do have to exist

favila18:06:56

yeah, that’s true

JohnJ18:06:58

(have been created beforehand)

favila18:06:12

attribute predicates can now give you some safety there

favila18:06:15

for ordinary values

JohnJ18:06:15

querying is also a bit more tedious with idents