Increase API parity with levelup
#383
Conversation
Non-breaking because these were undocumented and temporary options for internal `levelup` compatibility tests.
Very similar to `levelup` but more precise. If `open()` and `close()` are called repeatedly (while the previous call has not yet completed) the last call dictates the final status. Callbacks are not called until any pending state changes are done, meaning that the status is not 'opening' or 'closing'. Same for events. For example, in a sequence of calls like `open(); close(); open()` the final status will be 'open', only the second call will error, only an 'open' event is emitted, and all callbacks will see that status is 'open'. The callbacks are called in the order that the `open()` or `close()` calls were made. In addition, unlike on `levelup`, it is safe to call `open()` while status is 'closing'. It will wait for closing to complete and then reopen. We should now have complete safety, including in `leveldown` because the native code there delays `close()` if any operations are in flight. In other words, the JavaScript side in `abstract-leveldown` prevents new operations before opening the db, and the C++ side in `leveldown` prevents closing the db before operations completed. Ref Level/leveldown#8 Ref Level/community#58
Further improves safety, because it ensures an iterator can not be used after closing and reopening the db.
|
Complexity is slowly increasing here and I'm wary of that. So far it's still worth it. I find the behavior easier to oversee, and reimplementing certain I've been canary testing this against various modules; |
|
Funny how this is starting to look like the
Technically that still works (with a few tweaks in |
With tests imported from `levelup`, `encoding-down` and `memdown`. Has a temporary github dependency: `Level/transcoder`.
For lack of TextEncoder.
Biting the bullet. This adds promise support, makes
open()&close()idempotent, adds open and close events, makes anabstract-leveldowndb safer than alevelupdb, and more.Needs a ton of (canary) tests. Contains a few subtle breaking changes, but for consumers of downstream implementations it should be painless. An
abstract-leveldowndb can still be wrapped withlevelupand folks can continue to use that interface.I'm opening this up for early review, I might take it even further.
Ref Level/community#58
Ref Level/leveldown#8