Arun Mani
2017-11-02 00:59:50 UTC
The Datomic documentation
(http://docs.datomic.com/identity.html#unique-identities) suggests keeping
database-wide unique identities like email ids as "unique identity"
attributes. There aren't any usecases mentioned in the same documentation
for "unique value" attributes except to point out the critical difference
that they throw an exception if a datom with that attribute and value
combination already exists in the latest version of the db.
My own experience suggests though, in cases where we create entities with
database-wide unique ids (say, user accounts with a unique username
attribute), "upsert" semantics do not work well while creating such user
account entities, and I will need a transaction function to create these
correctly. Otherwise we may have a potential race condition if two users
create accounts with identical usernames around the same time. The only way
out is to write a transaction function for creating new user accounts.
On the other hand, the exception mechanism of "unique value" attributes are
exactly what I want for this usecase. I try to add a new user, and if I get
an 'IllegalStateException' I know there is a duplicate account with the
same username. (I should, of course, still check the current db as a first
step so as not to bother the transactor with easily spotted duplicate
requests.) The price I pay for this is that at update time I lose 'upsert',
and so will need to translate the value of the username attribute to a
Datomic entity id to be
able to update that user account. (I personally think that the lookup refs
mean that this isn't too much of a price to pay.)
So am I correct in understanding that the choice between "unique identity"
and "unique value" in my case is a choice between
1) being able to work with domain values directly for update operations but
at the cost of a tx function for the initial creation operation, or
2) having to use a 'lookup ref' for update operations but without the cost
of writing a tx function for the initial creation.
If this is correct, the Datomic documentation should preferably explain
this, and if this is not correct, please correct my misunderstanding.
Thanks,
- Arun
(http://docs.datomic.com/identity.html#unique-identities) suggests keeping
database-wide unique identities like email ids as "unique identity"
attributes. There aren't any usecases mentioned in the same documentation
for "unique value" attributes except to point out the critical difference
that they throw an exception if a datom with that attribute and value
combination already exists in the latest version of the db.
My own experience suggests though, in cases where we create entities with
database-wide unique ids (say, user accounts with a unique username
attribute), "upsert" semantics do not work well while creating such user
account entities, and I will need a transaction function to create these
correctly. Otherwise we may have a potential race condition if two users
create accounts with identical usernames around the same time. The only way
out is to write a transaction function for creating new user accounts.
On the other hand, the exception mechanism of "unique value" attributes are
exactly what I want for this usecase. I try to add a new user, and if I get
an 'IllegalStateException' I know there is a duplicate account with the
same username. (I should, of course, still check the current db as a first
step so as not to bother the transactor with easily spotted duplicate
requests.) The price I pay for this is that at update time I lose 'upsert',
and so will need to translate the value of the username attribute to a
Datomic entity id to be
able to update that user account. (I personally think that the lookup refs
mean that this isn't too much of a price to pay.)
So am I correct in understanding that the choice between "unique identity"
and "unique value" in my case is a choice between
1) being able to work with domain values directly for update operations but
at the cost of a tx function for the initial creation operation, or
2) having to use a 'lookup ref' for update operations but without the cost
of writing a tx function for the initial creation.
If this is correct, the Datomic documentation should preferably explain
this, and if this is not correct, please correct my misunderstanding.
Thanks,
- Arun
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.