-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge levelup into abstract-leveldown #58
Comments
I'm all for simplifying. There's also an issue of performance. Maybe we could benchmark the hell out of
Love the picture btw. This style is really nice. We should reuse it for documentation, blog post etc. How did you make it? |
Photoshop. I wanted to try its 3D features. And I'm never gonna do it again, lol. Took 10 crashes and retries and then 20 minutes waiting time just to render some damn plastic material 😄 |
This comment has been minimized.
This comment has been minimized.
I say yes. The first version can and should be a drop-in replacement. To keep all the history and get regression tests for free. Rough roadmap
The fork provides a starting point for later breaking changes, and a turning point for dependents: when they make the switch from Let's make encodings "phase 2". |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
💡 If |
Calling this |
I think it will be easier to do this the right way from the get-go. I want to support encodings out of the box, replacing both |
So that when `abstract-leveldown` starts using `level-errors`, and such a db is wrapped with `levelup`, `levelup` will not rewrap errors and lose stack trace information in the process. I.e.: ``` // Error created by abstract-leveldown const err = new ReadError('example') // Error created by levelup const wrapped = new ReadError(err) assert(wrapped === err) ``` Ref Level/community#58
So that when `abstract-leveldown` starts using `level-errors`, and such a db is wrapped with `levelup`, `levelup` will not rewrap errors and lose stack trace information in the process. I.e.: ``` // Error created by abstract-leveldown const err = new ReadError('example') // Error created by levelup const wrapped = new ReadError(err) assert(wrapped === err) ``` Ref Level/community#58
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
This thread got messy with my frequent edits and inline task lists. Continuing at https://github.com/Level/abstract-level. |
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
This is just an idea at this point, briefly discussed offline; we're not committing to anything. The premise: make any
abstract-leveldown
implementation a standalone, ready-to-go database.Refactorings in the past years have increased modularity. It has allowed us to clean up various internals. That said, now that we have, there are downsides to the current architecture, with its many layers:
level
means having to peel off layers first, then add them back (most notably insubleveldown
- that code is gnarly)leveldown
by itself returns Buffers by default,level(up)
returns strings by default).encoding-down
, serialization,asBuffer
, and whatever the underlying storage does (e.g. IDB returning a Buffer as Uint8Array). Yet for anabstract-leveldown
implementation there's no builtin primitive to decode/deserialize data.level
links tolevelup
links toencoding-down
links tolevel-codec
gives an example aboutleveldown
links tolevel
- you get the point)abstract-leveldown
layer, but that doesn't make it available to levelup per se) (related: plugin extension points: merge level-hooks / level-sublevel #44).Back to the idea: there are many open questions. Making a POC is probably the best way forward. To be clear: I don't want it to be a big batteries-included database. I think what we need are simpler primitives to enable composing (and maintaining!) such a database. Some "batteries" could be worth including, if they provide a foundation for userland modularity.
We have been recommending people to use
levelup
, and more so,level
and friends, which is a clear indication that much of the functionality belongs in a single core component. Or to put it in other words, a single shell (the public API ofabstract-leveldown
) around a nut (the private API ofabstract-leveldown
).The text was updated successfully, but these errors were encountered: