Don't allow violation of cardinality-one restrictions within a single transact.

[rnewman]

This requires maintaining a unique index so that we can INSERT OR REPLACE. The last value will win. We could also do INSERT OR IGNORE, check the number of changed rows, and throw.

This only works if the lookup ref succeeds. If it doesn't, then we're into #532.

Thoughts, @ncalexan?

[ncalexan]

In general, I think this is great. Perhaps a little expensive, but clear.

I have no strong opinion on OR REPLACE vs OR IGNORE. Last one wins -- i.e., transaction is processed in the order it is presented -- certainly seems to be most clear.

I am a little concerned that it violates Datomic's set-oriented model, but I am comforted by the fact that Datomic doesn't allow, for example, a schema change in the first datom transacted and then the use of the new schema fragment in subsequent datoms transacted. (In the same transaction.)

Does this not address the map notation bug you originally started from? If it does not, OK; if it does, please include a map notation test, since there is some hairy interleaving of the transactor stages that should be exercised.

[ncalexan]

Does this agree with Datomic? With DataScript?

[rnewman]

Datomic raises an error:

":db.error/datoms-conflict Two datoms in the same transaction conflict\n{:d1 [17592186045418 :test/one 123 13194139534313 true],\n :d2 [17592186045418 :test/one 124 13194139534313 true]}\n"

[rnewman]

We can't easily detect duplicates within a tx boundary: we can use INSERT and have an opaque error about uniqueness constraints being violated, which we wrap to Could not insert non-fts one statements into temporary search table!; use INSERT OR IGNORE and silently take the first value; or INSERT OR REPLACE and silently take the last (based on some permutation of the input order, I assume).

I think I'd prefer the opaque error, which we can improve in the future. I'll file that now.

[rnewman]

ef9f2d9 with a map notation test.