Fork me on GitHub
#datomic
<
2017-08-13
>
robert-stuttaford16:08:54

@hmaurer component only makes sense on refs, and i don’t think you can unique a ref. perhaps a schema code example to explain what you mean? 🙂

hmaurer16:08:18

@robert-stuttaford Hi! Are you sure about this? I just tried :db/unique :db.unique/value on a :db.type/ref attribute and it seems to behave as expected

hmaurer16:08:53

Which makes sense as, as far as I understand, a ref is just an ID (long or something?)?

hmaurer16:08:52

(by behave as expected I mean it does throw an exception if trying to transact the same ref twice)

hmaurer16:08:54

And an example would be “Users” who have an “Account”. If, in a particular application, each user has a distinct account which is referenced by :user/account, then it makes sense to make :user/account unique.

hmaurer16:08:51

The reason why I mentioned :db/isComponent is that it seemed to me that every ref that is a component should also be unique (as far as I can see)

hmaurer16:08:18

Unless I am mistaken, the semantics of :db/isComponent are that whenever a “parent” entity is retracted, its components are also retracted, recursively

hmaurer16:08:03

Say you have two entities A and B, where B is a component of A (e.g. there is a ref from A to B with :db/isComponent true)

hmaurer16:08:03

I cannot think of a scenario in which you would want other entities to hold refs to B with the same attribute

hmaurer16:08:11

in a sense, B “belongs to A”

favila17:08:38

You can unique a ref

favila17:08:40

The expected invariants of an isComponent are redundant with the unique-value invariants. If you want a little more safety, go ahead

favila17:08:02

But it's still not enough for full safety

favila17:08:19

An isComponent-referenced entity should only be in the V of a single datoms in the entire database (for a given t)

favila17:08:56

Unique-value will only guarantee it's in a single V for a given attribute

hmaurer17:08:36

What is the reasoning for “should only be in the V of a single datoms”? I agree though, it’s the conclusion I came to regarding a given attribute

favila17:08:19

You don't want any references to that entity from other attributes either

favila17:08:50

Otherwise you will have a surprise when you db.fn/retractEntity

hmaurer17:08:21

@favila makes sense, thanks! So the conclusion is: the invariants expected by isComponent are stronger than :db.unique/value, but are not enforced. Adding :db.unique/value enforces part of the expected invariants.

hmaurer17:08:41

Follow up question: is there any significant cost in marking attributes as unique?

hmaurer17:08:53

e.g. can I afford to mark a lot of attributes in my DB as unique?

hmaurer17:08:01

and can unique constraints be dropped later on?

hmaurer17:08:11

dropped and/or added

favila17:08:29

Indexing time and disk space are the only cost. You can change constraints later