feat: Feature gate traits inside storage-api that still depend on db-api #14647
Conversation
frankudoags
requested review from
joshieDo,
rkrasiuk,
rakita and
shekhirin
as code owners
frankudoags
requested review from
mattsse,
Rjected,
onbjerg and
klkvr
as code owners
| #[cfg(feature = "db-api")] | ||
| use reth_db_api::table::Table; | ||
| use reth_storage_errors::provider::ProviderResult; | ||
|
|
||
| /// The trait for fetching provider statistics. | ||
| #[cfg(feature = "db-api")] |
There was a problem hiding this comment.
these we don't need if we instead put the feature above mod stats;
There was a problem hiding this comment.
will fix, leftover from iterations.
There was a problem hiding this comment.
this should be compatible?
so we dont need a feature here?
There was a problem hiding this comment.
BlockNumberAddress is declared inside of dp-api, and the StorageChangeSetReader trait uses that, hence the need for the feature over that trait alone
There was a problem hiding this comment.
right, actually we should move these to db-models
opening an issue for this
There was a problem hiding this comment.
Will take it up. That particular type is indeed supposed to live in db-models.
There was a problem hiding this comment.
I think here we want to group all of the db-api traits into its own module, like
#[cfg("db-api)]
pub use db::*;
#[cfg("db-api)]
mod db {
....
}
There was a problem hiding this comment.
noted, cleaner too. Will fix
Feature gate traits inside storage-api that still depend on db-api, updates reth-provider features flag for storage-api dependency to include new db-api feature