[views] Cache the (:db/tx, :db/txInstant) relation #250

Open
opened 2020-08-06 16:57:21 +00:00 by gburd · 0 comments
gburd commented 2020-08-06 16:57:21 +00:00 (Migrated from github.com)

One thing I'm finding as a consumer of Mentat is that I need to turn transaction IDs (:db/tx) into (local) transaction instants (:db/txInstant) a good deal. In the future, I'll need to index into transaction IDs by local (and, with potential for confusion, incomparable remote) transaction instants. In the same way that we cache the (:db/id, :db/ident) relation for translating entids and idents locally, perhaps we should cache the (:db/tx, :db/txInstant) relation.

There are a lot of ways to achieve this. It's pretty easy to just "wire it in" to the transactor as another special table in the SQL store. It's also easy to materialize it each time the store is opened, and update it like we do the rest of the schema. There's existing work to cache attributes that we might leverage.

There are things we might be able to do with this. For example, we might make it easy to turn a tx ref into a txInstant coming out of a query, say like:

[:find (tx-instant ?tx)
 :where [_ _ _ ?tx]]

(That's really what I'm tired of doing -- manually inserting [?tx :db/txInstant ?txI] clauses to convert in the query body.) Although post-processing functions like this need care, because it's not clear what should happen when tx-instant: Ref -> Option<Instant> returns None.

In any case, something to think about. Just being able to binary search a big list of the relation wouldn't be a bad outcome for me.

One thing I'm finding as a consumer of Mentat is that I need to turn transaction IDs (`:db/tx`) into (local) transaction instants (`:db/txInstant`) a good deal. In the future, I'll need to index into transaction IDs by local (and, with potential for confusion, incomparable remote) transaction instants. In the same way that we cache the `(:db/id, :db/ident)` relation for translating entids and idents locally, perhaps we should cache the `(:db/tx, :db/txInstant)` relation. There are a lot of ways to achieve this. It's pretty easy to just "wire it in" to the transactor as another special table in the SQL store. It's also easy to materialize it each time the store is opened, and update it like we do the rest of the schema. There's existing work to cache attributes that we might leverage. There are things we might be able to do with this. For example, we might make it easy to turn a `tx` ref into a `txInstant` coming out of a query, say like: ``` [:find (tx-instant ?tx) :where [_ _ _ ?tx]] ``` (That's really what I'm tired of doing -- manually inserting `[?tx :db/txInstant ?txI]` clauses to convert in the query body.) Although post-processing functions like this need care, because it's not clear what should happen when `tx-instant: Ref -> Option<Instant>` returns `None`. In any case, something to think about. Just being able to binary search a big list of the relation wouldn't be a bad outcome for me.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: greg/mentat#250
No description provided.