[views] Cache the (:db/tx, :db/txInstant) relation #250
Labels
No labels
A-build
A-cli
A-core
A-design
A-edn
A-ffi
A-query
A-sdk
A-sdk-android
A-sdk-ios
A-sync
A-transact
A-views
A-vocab
P-Android
P-desktop
P-iOS
bug
correctness
dependencies
dev-ergonomics
discussion
documentation
duplicate
enhancement
enquiry
good first bug
good first issue
help wanted
hygiene
in progress
invalid
question
ready
size
speed
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: greg/mentat#250
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 atxInstant
coming out of a query, say like:(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 whentx-instant: Ref -> Option<Instant>
returnsNone
.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.