@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? 🙂

@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

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

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

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.

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)

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

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)

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

in a sense, B “belongs to A”

You can unique a ref

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

But it's still not enough for full safety

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

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

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

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

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

@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.

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

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

and can unique constraints be dropped later on?

dropped and/or added

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