-
Notifications
You must be signed in to change notification settings - Fork 6
Rewrite project as thin wrapper on react-native-leveldb #7
Comments
I don't expect I'll get to this anytime soon; patches welcome! Should be pretty straightforward… |
Hi Andy, nice to see this! As I've said before, let me know if you run into any kinks (e.g. I just discovered that I forgot Prev(), planning to add it soon.) I wanted to add to one thing you said -
For many types of usages (e.g. ~100 reads/writes in response to a user action) I bet that keeping it sync is a good trade-off. Maybe we could bake something like this in your wrapper, where it yields execution every XX operations, or even make it an option. If somebody is used to the async nature of leveldown, they might be surprised to see their app locking, if they fetch a larger number of keys (thousands+); previously, the async implementations of leveldown would have yielded execution to other parts of the app (like rendering views). |
Yep, I agree with your broad conclusions: keeping it async as default probably promotes "least surprise," especially when coupled with reasonable heuristics like batching iterator |
Now that @savv has written a TurboModules implementation of the native LevelDB bindings (https://github.com/greentriangle/react-native-leveldb), this library should become a thin
abstract-leveldown
adapter for that interface:One observation: that library supports synchronous access of the DB, while
abstract-leveldown
mandates asynchronous semantics (i.e. insertingnextTick
even when data can be requested immediately). That seems like a shame; perhaps we should have some special high-performance option which retains the synchronous semantics, at the cost of breakingabstract-leveldown
's assumptions.The text was updated successfully, but these errors were encountered: