Make Snapshot
take a strategy trait so that users can write their own strategies
#82
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a
SnapshotStrategy
trait and adds a generic toSnapshot
,SnapshotMap
,SnapshotItem
, andIndexedSnapshotMap
. It also implements theSnapshotStrategy
trait for theStrategy
enum.This PR also adds a
IntervalStrategy
struct which is a strategy that only stores data to the changelog if at least a certain number of blocks has passed.I tried my best to make these changes non-breaking and I think I succeeded. However, I think there are more changes that could be make to simplify and improve
Snapshot
. For example, I found the "checkpointing" and the fnassert_checkpointed
quite confusing and it seems this is only used in theStrategy::Selected
variant. I couldn't figure out a way to move this logic into this variant without making breaking changes.I also found it a bit unintuitive that in
SnapshotMap
, data added to the changelog use the current height and not the height at which they were originally saved to theprimary
Map
. For the current purposes that I want to use SnapshotMap for it would make sense to use the height at which the data was originally saved, so that the changelog becomes a record of history rather than having a delay in the heights. Would you be interested in me adding an alternative implementation that accomplishes this? Trying to modify the current implementation would cause breaking changes.