Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
add engine_traits component #5445
Signed-off-by: 5kbpers firstname.lastname@example.org
What have you changed?
Separate from #5237.
What is the type of the changes?
How is the PR tested?
Does this PR affect documentation (docs) or should it be mentioned in the release notes?
Does this PR affect
Thank you so much @5kbpers. This is very easy to understand. I appreciate it.
Organizationally there's one change I would like to see here, and that's to put the RocksDB implementation in a different crate, such that engine_traits does not depend on rocksdb.
What we want to end up with, for the sake of compile time, and also simply maintaining abstraction boundaries, is one crate that defines what an engine is (its traits), and for each implemented engine, another crate that implements those traits. That way the common code will build very fast, from there all the engines will build in parallel, and the implementation details of the engines can't leak into the common code or each other.
It makes sense for the rocksdb implementation to be in a crate named
It is though nice to have a clean slate to write the rocks impls like you have here, where the rocks trait impls are not intermixed with the existing body of code. Keeps all the details of the rocks bindings from obscuring the trait implementations. So I think you should either: put the rocks impls in an entirely new crate that depends on both engine_traits and engine_rocksdb (perhaps with the aim of renaming engine_rocksdb to something else so that engine_rocksdb can just be used for the trait impls); or just make a new top-level module in engine_rocksdb, e.g.
I'd also prefer if you split these two steps into two commits, one for defining the traits, and one four outlining the rocksdb implementation, though I admit that this single commit is perfectly comprehensible as as. (Edit: don't bother doing this)
This looks good to me now. It looks like @5kbpers you've removed the rocks impls from this PR. I'm sorry if I sounded like I wanted that, but still this is a fine place to start.
@aknuds1 still has some points of clarification that I hope you will address, so I'm not clicking the approve button yet. I don't have opinions about the whitespace issues but the typos are worth fixing.