The underlying Dag for a COB will use the Ord implementation of
whatever is provided as the key. This means that the lexicographical
ordering of the Oid SHA will be used, which in turn means that if
the SHAs change in our tests, then the ordering will be broken for
concurrent updates.
To prevent this from happening, a new key is used EntryKey, which is
the combination of an Oid and a Timestamp – the commit
timestamp. The key is used in place of EntryId as the Dag key.
This introduction meant that in some places it was necessary to have a
way of getting the timestamp of an EntryId. The TimestampOf trait
is used in these cases, which means that some infallible functions
became fallible.
The underlying Dag for a COB will use the Ord implementation of
whatever is provided as the key. This means that the lexicographical
ordering of the Oid SHA will be used, which in turn means that if
the SHAs change in our tests, then the ordering will be broken for
concurrent updates.
To prevent this from happening, a new key is used EntryKey, which is
the combination of an Oid and a Timestamp – the commit
timestamp. The key is used in place of EntryId as the Dag key.
This introduction meant that in some places it was necessary to have a
way of getting the timestamp of an EntryId. The TimestampOf trait
is used in these cases, which means that some infallible functions
became fallible.
Changes:
- rebased
- changed commit message to use the terminology “chronlogical ordering” rather than “stable ordering”
Changes:
- Approach the problem from the
DagAPI, introducing aprune_bymethod which is used in place ofprune, and allows us to dictate the ordering based on the key and value pairs.
Changes:
- Reverting some erroneuous changes
Changes:
- Add test for
prune_by - Do not take
orderingby reference inprune_by