Skip to content
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

kvdb-rocksdb: pass ReadOptions to iterators #277

Merged
merged 7 commits into from
Dec 19, 2019

Conversation

ordian
Copy link
Member

@ordian ordian commented Dec 3, 2019

Copy link
Contributor

@dvdplm dvdplm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty confusing, apologies if I'm misunderstanding this.

In order to use prefix search users must create a prefix extractor (rocksdb::SliceTransform::create_fixed_prefix(…)) when opening the DB and then pass it along when instantiating an iterator, is that correct?

The test_prefix_iterator() test in rust-rocksdb uses a different type though: Options (i.e. ffi::rocksdb_options_t) – do both work?

I think we have two options here:

  • land this PR here (with more docs/examples illustrating usage)
  • audit code using the prefix search and figure out if it really needs to; if, as I suspect, we're not using this, then maybe it's better to just remove support for it.

@ordian
Copy link
Member Author

ordian commented Dec 4, 2019

audit code using the prefix search and figure out if it really needs to; if, as I suspect, we're not using this

we are: 1, 2.

In order to use prefix search users must create a prefix extractor (rocksdb::SliceTransform::create_fixed_prefix(…)) when opening the DB and then pass it along when instantiating an iterator, is that correct?

yes

The test_prefix_iterator() test in rust-rocksdb uses a different type though: Options (i.e. ffi::rocksdb_options_t) – do both work?

set_prefix_extractor is set on Options (this is a global option, which affects the db layout, db is partitioned based on prefix),
set_prefix_same_as_start is called on ReadOptions when creating an Iterator
https://docs.rs/rocksdb/0.13.0/src/rocksdb/db.rs.html#1153

@ordian
Copy link
Member Author

ordian commented Dec 4, 2019

(with more docs/examples illustrating usage)

what do you mean, we haven't changed the public API here

@dvdplm
Copy link
Contributor

dvdplm commented Dec 4, 2019

what do you mean, we haven't changed the public API here

True, but the docs for the existing API are lacking and do not mention how to set up the prefix search properly. I think we want an example here, docs here and probably module level docs discussing the quirks of prefix search too?

@dvdplm
Copy link
Contributor

dvdplm commented Dec 4, 2019

audit code using the prefix search and figure out if it really needs to; if, as I suspect, we're not using this

we are: 1, 2.

I see. So that code needs to be updated after this PR then? And does it even work right now?

@ordian
Copy link
Member Author

ordian commented Dec 4, 2019

So that code needs to be updated after this PR then?

no logic has changed

But I just realised that we changed the logic in #257 8fb8f13#diff-4382bfb7e75959b2b8884268540abfa3R597, previously iter_from_prefix returned an iterator over all keys >= prefix, now it only returns an iterator of keys starting with the given prefix. I thought it was the expected behavior, but not sure now :/

@ordian
Copy link
Member Author

ordian commented Dec 4, 2019

But I just realised that we changed the logic in #257

After a quick search, in parity-ethereum we use iter_from_prefix only in epoch_transitions and then we filter it to start with prefix here. The same thing happens in substrate:
usage, filter. So even though we've changed the logic in #257, it doesn't affect parity-ethereum and substrate. The question is: do we want the new behavior or the old one?

Copy link
Contributor

@dvdplm dvdplm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm modulo docs

}

impl<'a, T> ReadGuardedIterator<'a, <&'a T as IterationHandler>::Iterator, T>
where
&'a T: IterationHandler,
{
pub fn new(read_lock: RwLockReadGuard<'a, Option<T>>, col: Option<u32>) -> Self {
Self { inner: Self::new_inner(read_lock, |db| db.iter(col)) }
pub fn new(read_lock: RwLockReadGuard<'a, Option<T>>, col: Option<u32>, read_opts: &ReadOptions) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<insert illuminating example here>. – needs some editing... ;)

…and there are other methods that now take ReadOptions that needs some docs?

kvdb-rocksdb/src/iter.rs Show resolved Hide resolved
kvdb-rocksdb/src/lib.rs Show resolved Hide resolved
kvdb-rocksdb/src/iter.rs Outdated Show resolved Hide resolved
kvdb-rocksdb/src/iter.rs Outdated Show resolved Hide resolved
kvdb-rocksdb/src/iter.rs Outdated Show resolved Hide resolved
kvdb-rocksdb/src/iter.rs Outdated Show resolved Hide resolved
kvdb-rocksdb/src/iter.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@dvdplm dvdplm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still some docs that need some love, but overall lgtm.

}

impl<'a, T> ReadGuardedIterator<'a, <&'a T as IterationHandler>::Iterator, T>
where
&'a T: IterationHandler,
{
pub fn new(read_lock: RwLockReadGuard<'a, Option<T>>, col: Option<u32>) -> Self {
Self { inner: Self::new_inner(read_lock, |db| db.iter(col)) }
pub fn new(read_lock: RwLockReadGuard<'a, Option<T>>, col: Option<u32>, read_opts: &ReadOptions) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<insert illuminating example here>. – needs some editing... ;)

…and there are other methods that now take ReadOptions that needs some docs?

@dvdplm
Copy link
Contributor

dvdplm commented Dec 10, 2019

ping @bkchr

@dvdplm dvdplm requested a review from niklasad1 December 16, 2019 07:48
* master:
  Fix a typo in error rlp error message (#283)
  [kvdb*] Make column type u32 instead of Option<u32> (#278)
  [kvdb-rocksdb] Add benchmark for point lookups (#275)
  Compile triehash for no_std (#280)
Copy link
Member

@niklasad1 niklasad1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but I'm not super familiar with this code, thus would be good if @bkchr could sign off on it.

Copy link
Member

@bkchr bkchr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Besides the read lock in the comments it looks good.

@@ -78,22 +84,35 @@ pub trait IterationHandler {

/// Create an `Iterator` over the default DB column or over a `ColumnFamily` if a column number
/// is passed.
fn iter(&self, col: u32) -> Self::Iterator;
/// In addition to a read lock and a column index, it takes a ref to the same `ReadOptions` we
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why it talks about the read lock here? That is not part of the interface?

Same below.

@dvdplm dvdplm merged commit 5837dff into master Dec 19, 2019
@dvdplm dvdplm deleted the ao-pass-read-option-to-prefix-iter branch December 19, 2019 11:20
dvdplm added a commit that referenced this pull request Dec 19, 2019
* master:
  kvdb-rocksdb: pass ReadOptions to iterators (#277)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants