You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 1, 2024. It is now read-only.
Follow-up for TODO comments added in #725. Since that PR, the levelup interface has a status property the same as abstract-leveldown. It returns this.db.status.
Ideally levelup has its own status that is tracked separately from the underlying db. That way open events and externally seen status will be consistent. E.g. if the underlying db.status is initially 'open' (rather than 'new'), the levelup status should nevertheless be 'new', and the two states will "consolidate" upon open().
For API parity (Level/community#58) and simplicity, we should also prefer using db.status over these 3 utility methods: isOpen(), _isOpening() and isClosed(). Be aware that subleveldown uses those atm. Keep the isOperational() utility method because that expresses something different: whether operations can be made on the db regardless of its status.
Follow-up for TODO comments added in #725. Since that PR, the
levelupinterface has astatusproperty the same asabstract-leveldown. It returnsthis.db.status.Ideally
leveluphas its ownstatusthat is tracked separately from the underlyingdb. That wayopenevents and externally seen status will be consistent. E.g. if the underlyingdb.statusis initially 'open' (rather than 'new'), thelevelupstatus should nevertheless be 'new', and the two states will "consolidate" uponopen().For API parity (Level/community#58) and simplicity, we should also prefer using
db.statusover these 3 utility methods:isOpen(),_isOpening()andisClosed(). Be aware thatsubleveldownuses those atm. Keep theisOperational()utility method because that expresses something different: whether operations can be made on the db regardless of itsstatus.