search

andymatuschak / react-native-leveldown

Native bindings to LevelDB for React Native, exposed as leveldown-compatible interface
MIT License
22 stars 6 forks source link

Rewrite project as thin wrapper on react-native-leveldb #7

Open andymatuschak opened 3 years ago

andymatuschak commented 3 years ago

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. inserting nextTick 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 breaking abstract-leveldown's assumptions.

andymatuschak commented 3 years ago

I don't expect I'll get to this anytime soon; patches welcome! Should be pretty straightforward…

savv commented 3 years ago

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 -

One observation: that library supports synchronous access of the DB, while abstract-leveldown mandates asynchronous semantics (i.e. inserting nextTick 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 breaking abstract-leveldown's assumptions. This sounds like a great idea! I see the trade-off as follows:

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).

andymatuschak commented 3 years ago

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 nexts (which this library currently does). More synchronous behavior should probably be opt-in.