Calling .undo() does not update the head in the Hypercore, it returns a new Hyperbee that points to an old batch. However, it is writable. And writing on top of the new Hyperbee instance will append a batch to the Hypercore. This all makes sense at an implementation level but can lead to some potentially confusing behaviour for consumers of this library.
If, as I expect is normally the case, a user of this library simply opens a corestore path to use as a Hyperbee, then calling .undo() does not persist any rollback. However, calling undo() followed by flushing a WriteBatch will persist the rollback.
This either needs clearly documenting, or the undo (as exposed in the public API) should write a new batch without extra operations to persist the change so it is still applied next time the corestore path is opened.
Calling
.undo()does not update the head in theHypercore, it returns a newHyperbeethat points to an old batch. However, it is writable. And writing on top of the newHyperbeeinstance will append a batch to theHypercore. This all makes sense at an implementation level but can lead to some potentially confusing behaviour for consumers of this library.If, as I expect is normally the case, a user of this library simply opens a corestore path to use as a Hyperbee, then calling
.undo()does not persist any rollback. However, callingundo()followed by flushing aWriteBatchwill persist the rollback.This either needs clearly documenting, or the undo (as exposed in the public API) should write a new batch without extra operations to persist the change so it is still applied next time the corestore path is opened.