We’re trying to use unique composite-tuples (with ref attributes) to automatically generate unique identity attributes for multiple entities upserted in a single transaction.
If a unique attribute is a composite-tuple, normal Datomic upsert behavior doesn’t work unless the value of the composite tuple is provided directly (unique constraint violation on the tuple on all but the first upsert).
As an aside, this doesn’t quite match the docs here
“Composite attributes are entirely managed by Datomic–you never assert or retract them yourself.”
For cases where the unique composite-tuple’s attributes are scalars, this is workable for the use case I’m currently testing because at transaction time, those values are known. I expect this won’t always be true in other cases.
However, if the unique composite-tuple contains attributes that are refs, their entity-ids are not necessarily known if they upserted in the same transaction. Normally we’d use temp-ids in transactions to solve this kind of thing, but entity look-ups fail if temp-ids are used for refs in unique composite-tuples. It seems that specifying the Entity IDs for the ref attributes does work.
If the unique constraint on the composite-tuple is removed, the use of temp-ids works as expected for the composite-tuple’s attributes, but of course a unique entity is not resolved, a new entity is created, thus not achieving the desired upsert behavior.
To work around this, we are maintaining our own entity-id schema, along with corresponding code to generate entity-ids as required; something we’d ideally leave to Datomic if possible.
Are there other solutions that we are missing here?
Could the fact that we can’t use temp-ids when asserting unique composite-tuples directly be considered a bug? Or perhaps that it’s required to assert unique composite-tuples directly at all?
Perhaps there are other ways to achieve the same thing?
Any suggestions would be much appreciated. 