RocksDB Adapter
HyperAlch opened this issue · comments
I'm looking into making a RocksDB adapter for this library (I can't stand Sled and I don't trust it).
If I end up getting around to doing it, would this be something you would be interested in adding to the main repo, or would you rather me just fork the project and have it be it's own thing?
If it's entirely optional and don't complicate the API, I'm all for it. I'd like the default features to be a all pure rust dependenies though.
What's wrong with sled, though?
Directly from their "known issues, warnings"
if reliability is your primary constraint, use SQLite. sled is beta.(I need reliability)quite young, should be considered unstable for the time being.(I need something that isn't going to brick the progress my game designers make using my game engine built on top of bevy)the on-disk format is going to change in ways that require manual migrations before the 1.0.0 release!
These issues would be fixed over time. However, Sled hasn't had a major release since September 12, 2021
RocksDB had it's last release 2 weeks ago
I honestly don't have enough faith in the project to put it in my game engine.
I will let you know when I'm done with the adapter and we can talk about how you want to optionally add it to the main repo. I'm assuming feature flags in the users cargo.toml file, but we can worry about that later.
Alright, fair enough. If it's (semi-) abandoned, that's a really good reason to switch the default to something else. I just kind of dislike C++ deps, as they often make cross-compiling a pain.
According to this Rust RocksDB wrapper: https://github.com/rust-rocksdb/rust-rocksdb
The requirements are Clang and LLVM which are pretty common packages. However, I do see your point with c++ deps and as long as sled isn't causing major issues, keeping that as default for now sounds fine. I just think it would be beneficial to have a 2nd option for people who want it. I just picked RocksDB based on preference, but there are others like it out there. You could even use Sqlite if you really wanted to. But i'll work on the RocksDB adapter and if it works out other people can add their own adapters as needed. As long as it doesn't complicate things, the more choices the better in my opinion.
I if don't misremember, I tried sqlite or some other db, but found it kind of hard to make it work with the current API because it required async or something similar to flush changes.