225 added partial support for :db/tx in the transactor, but it's not quite complete; this ticket tracks completing it by allowing :db/tx in the entity column (so that additional metadata about the transaction can be recorded) and in the value column (so that data can refer to the current transaction).
:db/tx is rather special, since it's a reference whose resolved entid varies with the transaction. That's similar to, but in the implementation very different to, :db/txInstant, which is an attribute. In particular, since :db/txInstant is in the core schema, we never need to worry about resolving it specially.
:db/tx, however, is a special value that doesn't exist in the (core) schema. The initial support in #225 added it as a special tempid, and added special parsing support to produce it from EDN input. It's not a bad approach, but it doesn't accommodate the entity builder, which bypasses EDN input entirely. And I don't think that the tests are comprehensive, so I'm not convinced it is correctly resolved in both the a and v columns even when coming from EDN.
ncalexan
commented
6 years ago
225 added partial support for
:db/txin the transactor, but it's not quite complete; this ticket tracks completing it by allowing:db/txin the entity column (so that additional metadata about the transaction can be recorded) and in the value column (so that data can refer to the current transaction).:db/txis rather special, since it's a reference whose resolved entid varies with the transaction. That's similar to, but in the implementation very different to,:db/txInstant, which is an attribute. In particular, since:db/txInstantis in the core schema, we never need to worry about resolving it specially.:db/tx, however, is a special value that doesn't exist in the (core) schema. The initial support in #225 added it as a special tempid, and added special parsing support to produce it from EDN input. It's not a bad approach, but it doesn't accommodate the entity builder, which bypasses EDN input entirely. And I don't think that the tests are comprehensive, so I'm not convinced it is correctly resolved in both theaandvcolumns even when coming from EDN.