-
Notifications
You must be signed in to change notification settings - Fork 17
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
rocksdb
feature flag
#136
rocksdb
feature flag
#136
Conversation
Signed-off-by: muraca <[email protected]>
Signed-off-by: muraca <[email protected]>
My first thoughts were, "Is this really necessary, is parity db good enough, does Tuxedo need to be opinionated about the DB, etc". But the compile time is a pretty compelling reason. How many hours have I wasted and CO2 emitted compiling So in the end I actually do support this change, I just request that you document this a little bit better because this is a template and we don't want users getting confused and frustrated by things that are not so core to Tuxedo. So for example, please provide a better PR description. And maybe also a comment in the FYI, if the rock-db feature is enabled, the default DB is rocks DB. And it is a default feature. So in that sense, the default in the ecosystem is still to use Rocks DB. |
Edit: I will do it this way. It's a clean and elegant solution. |
Signed-off-by: muraca <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also thought their way of determining the default was overkill. I wonder if it is for backwards compatibility for nodes that ahve been running since before parity db?
Anyway, I'm happy with the way you have it and look forward to the faster builds.
Use ParityDB as the default database, and allow RocksDB to be used by compiling the node with the feature flag
rocksdb
.This was done because building RocksDB is only a waste of time and resources if used for CI and tests.