feat: add Metadata table and StorageSettings to ProviderFactory#19384
feat: add Metadata table and StorageSettings to ProviderFactory#19384
Metadata table and StorageSettings to ProviderFactory#19384Conversation
3293ca2 to
b4e32d6
Compare
49ada86 to
62b4443
Compare
| pub struct StorageSettings { | ||
| /// Whether this node always writes receipts to static files. | ||
| /// | ||
| /// If this is set to FALSE AND receipt pruning IS ENABLED, all receipts should be written to DB. Otherwise, they should be written to static files. This ensures that older nodes do not need to migrate their current DB tables to static files. For more, read: <https://github.com/paradigmxyz/reth/issues/18890#issuecomment-3457760097> | ||
| pub receipts_on_static_files: bool, | ||
| } |
There was a problem hiding this comment.
can we make this so that we can easily extend this and store arbitrary info?
There was a problem hiding this comment.
yeah I think we will also want something for snap sync here, maybe we could change receipts_on_static_files to static_files_v2_enabled since I think I'll just reuse this value to determine whether or not to write changesets in #18882
maybe this should just be a map?
There was a problem hiding this comment.
couldnt we just add new booleans here as we need them and make the sf roll out changes more gradually?
There was a problem hiding this comment.
reth/crates/storage/storage-api/src/metadata.rs
Lines 35 to 39 in 6429250
this is also being encoded as serde_json so extending this should be fine
| /// Stores generic node metadata as key-value pairs. | ||
| /// Can store feature flags, configuration markers, and other node-specific data. | ||
| table Metadata { | ||
| type Key = String; | ||
| type Value = Vec<u8>; | ||
| } |
There was a problem hiding this comment.
oh I see this also works because then we can store arbitrary metadata entries like key value storage
| static_file_provider: StaticFileProvider<N::Primitives>, | ||
| prune_modes: PruneModes, | ||
| storage: Arc<N::Storage>, | ||
| storage_settings: Arc<RwLock<StorageSettings>>, |
There was a problem hiding this comment.
we might want to extend this in the future with things like snapsync node or smth, but for now i think this is okay
| Arc::new(RwLock::new(StorageSettings::default())), | ||
| ) | ||
| .storage_settings()? | ||
| .unwrap_or_default(); |
There was a problem hiding this comment.
this is correct here because this defaults to false, could we make this explicit with a constructor fn on StorageSettings
| Arc::new(RwLock::new(StorageSettings::default())), | ||
| ) | ||
| .storage_settings()? |
There was a problem hiding this comment.
this feels a bit strange, why does this need StorageSettings as input in order to return it?
There was a problem hiding this comment.
yeah it feels weird because its a bit cyclical, open to suggestions.
The overall idea is that both ProviderFactory and DatabaseProvider are instantiated with a cached storage settings object. But to obtain it in the first place, ProviderFactory needs to create a DatabaseProvider to fetch it from storage. That's what's happening here.
e5d730d to
eea160a
Compare
eea160a to
6429250
Compare
| static_file_provider.clone(), | ||
| Default::default(), | ||
| Default::default(), | ||
| Arc::new(RwLock::new(legacy_settings)), |
There was a problem hiding this comment.
hmm, isn't this the same as creating Self first and then updating the storage_settings?
| let legacy_settings = StorageSettings::legacy(); | ||
| let storage_settings = DatabaseProvider::<_, N>::new( |
There was a problem hiding this comment.
please document what's going on here, why are we doing this
towards #18890 (comment)
Metadatatable.StorageSettingsentry to above table.StorageSettingsoninit_genesisProviderFactoryandDatabaseProviderand afterinit_genesis#19384 <- #19399 <- #19401