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

Open unknown columns in the RocksDB for forward compatibility #2079

Merged
merged 3 commits into from
Aug 14, 2024

Conversation

xgreenx
Copy link
Collaborator

@xgreenx xgreenx commented Aug 14, 2024

Rocksdb requires opening all columns mentioned in the Manifest file. This means that old versions of the fuel-core are unable to open columns created by a new version of the fuel-core. The change adds forward compatibility by opening unknown columns with default options.

Checklist

  • New behavior is reflected in tests

Before requesting review

  • I have reviewed the code myself

@xgreenx xgreenx requested a review from a team August 14, 2024 12:46
@xgreenx xgreenx self-assigned this Aug 14, 2024
@xgreenx xgreenx changed the title Open unknown columns in the RocksDB for backward compatibility Open unknown columns in the RocksDB for forward compatibility Aug 14, 2024
@xgreenx xgreenx enabled auto-merge (squash) August 14, 2024 13:49
Copy link
Member

@rymnc rymnc left a comment

Choose a reason for hiding this comment

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

LGTM, left a question and a nit in-line :)

Comment on lines +329 to +339
for column_name in existing_column_families {
if cf_descriptors_to_open.contains_key(&column_name)
|| cf_descriptors_to_create.contains_key(&column_name)
{
continue;
}

let unknown_column_name = column_name;
let unknown_column_options = Self::default_cf_opts(&block_opts);
cf_descriptors_to_open.insert(unknown_column_name, unknown_column_options);
}
Copy link
Member

Choose a reason for hiding this comment

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

how about this?

Suggested change
for column_name in existing_column_families {
if cf_descriptors_to_open.contains_key(&column_name)
|| cf_descriptors_to_create.contains_key(&column_name)
{
continue;
}
let unknown_column_name = column_name;
let unknown_column_options = Self::default_cf_opts(&block_opts);
cf_descriptors_to_open.insert(unknown_column_name, unknown_column_options);
}
existing_column_families
.iter()
.filter(|column_name| {
!cf_descriptors_to_open.contains_key(*column_name)
&& !cf_descriptors_to_create.contains_key(*column_name)
})
.for_each(|column_name| {
let unknown_column_options = Self::default_cf_opts(&block_opts);
cf_descriptors_to_open.insert(column_name.clone(), unknown_column_options);
});

Copy link
Contributor

Choose a reason for hiding this comment

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

While this PR is merged without applying this suggestion, I also generally prefer using iterators to populate collections over using for loops and .insert. In this scenario I would also have advised to use .map instead of .for_each, to avoid having to call .insert from within the for_each closure.

Something along the lines of:

cf_descriptors_to_open.extend(existing_column_families.iter().filter(...).map(...))

@@ -428,12 +441,18 @@ where
format!("col-{}", column)
}

fn cf_opts(column: Description::Column, block_opts: &BlockBasedOptions) -> Options {
fn default_cf_opts(block_opts: &BlockBasedOptions) -> Options {
Copy link
Member

Choose a reason for hiding this comment

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

qq: where do we describe the column to use in default_cf_opts?

@xgreenx xgreenx merged commit e32f1f0 into master Aug 14, 2024
34 checks passed
@xgreenx xgreenx deleted the feature/forward-compatibility-rocksdb branch August 14, 2024 18:25
xgreenx added a commit that referenced this pull request Aug 15, 2024
Addressed comments in the unknown columns PR
#2079.

### Before requesting review
- [x] I have reviewed the code myself
@xgreenx xgreenx mentioned this pull request Aug 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants