Temp-ids

[alex-dixon]

Forget why we don't have this already. Could implement the same way Datomic does, i.e. automatically assign (util/guid) to any fact inserted with a negative int and allow references with the same negative int to resolve to the same guid.

Example:

(insert! [[-1 :todo/title "foo"]
              [-1 :todo/done true]
              [-2 :todo/title "bar"]
              [-2 :todo/done true]])

[alex-dixon]

IMO this would add to the dev experience significantly.

However, Datomic's implementation is more than "generate an id for x and use it whenever you see x":

From the docs:

In general, unique temporary ids are mapped to new entity ids. However, there is one exception. When you add a fact about a new entity with a temporary id, and one of the attributes you specify is defined as :db/unique :db.unique/identity, the system will map your temporary id to an existing entity if one exists with the same attribute and value (update) or will make a new entity if one does not exist (insert). All further adds in the transaction that apply to that same temporary id are applied to the "upserted" entity. emphasis added

This is not as trivial to implement. We'd need to manage a temp-id atom that gets reset on every insert/retract and store temp-id -> actual-id, and figure out what should happen when we receive a request to insert two unique facts with the same temp id (second one wins?).

Suppose we get a request to insert a fact F that with temp id x. Our index functions would need to (not exactly this or in this order as there's branching logic): 0. Check temp-ids atom and use x if there's a value for it.

1. Check the unique index for a -> v.
2. If exists a -> v, x is the :e of the fact at a -> v. Store :e in hash map x -> :e
3. If not exists a -> v, x is (guid). Assoc in temp-id atom x -> guid
4. F is now [e :attr ...]. Index per normal.

If implemented we could gain the ability to talk about entities that have unique a -> v combinations without knowing their eid (i.e. "lookup refs").