This is based on @Blajda's work in #2327 and aims to revive transactions identifiers.
This PR elaborates a bit on the ReplayVisitor concept introduced by David. specifically we moved things "one level down" to be tracked on the eager snapshot. This was mainly required to make it work with the commit flow, to properly handle updating the state after commits, without piping the visitors through all the ways.
The nice thing about this, that we can isolate the mechanics as to when or how we track additional actions in the EagerSnapshot and expose an interface the looks like what we might get for kernel - i.e. some opaque iterator over the respective actions.
Description
This is based on @Blajda's work in #2327 and aims to revive transactions identifiers.
This PR elaborates a bit on the
ReplayVisitorconcept introduced by David. specifically we moved things "one level down" to be tracked on the eager snapshot. This was mainly required to make it work with the commit flow, to properly handle updating the state after commits, without piping the visitors through all the ways.The nice thing about this, that we can isolate the mechanics as to when or how we track additional actions in the
EagerSnapshotand expose an interface the looks like what we might get for kernel - i.e. some opaque iterator over the respective actions.Related Issue(s)
closes #2130
Documentation