blockchain: Introduce BlockchainMap and BlockchainKind
#2755
Conversation
leoyvens
force-pushed
the
leo/blockchain-map
branch
from
968193b to
7c944d3
Compare
| .ok_or(SubgraphRegistrarError::NetworkNotSupported( | ||
| network_name.clone(), | ||
| ))? | ||
| .cheap_clone(); |
There was a problem hiding this comment.
This block of code was moved to the create_subgraph_version free function.
| let validation_warnings = import_errors | ||
| .into_iter() | ||
| .map(SubgraphManifestValidationWarning::SchemaValidationWarning) | ||
| .collect(); |
There was a problem hiding this comment.
These import_errors are not used anyways, so they are now ignored.
| @@ -921,40 +917,12 @@ impl<C: Blockchain> UnvalidatedSubgraphManifest<C> { | |||
|
|
|||
| impl<C: Blockchain> SubgraphManifest<C> { | |||
| /// Entry point for resolving a subgraph definition. | |||
| /// Right now the only supported links are of the form: | |||
| /// `/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k` | |||
| pub async fn resolve( | |||
There was a problem hiding this comment.
Removed because resolve_from_raw is now used in all cases.
| // `blockchain_map`. | ||
| let mut blockchain_map = BlockchainMap::new(); | ||
| let ethereum_chains = networks_as_chains( | ||
| &mut blockchain_map, |
There was a problem hiding this comment.
This hack is because I preferred to not refactor the block ingestor to use BlockchainMap since it is unlikely to be used for new chains, so ethereum_chains continues to exists.
| @@ -1024,6 +992,7 @@ impl<C: Blockchain> UnresolvedSubgraphManifest<C> { | |||
| self, | |||
| resolver: &impl LinkResolver, | |||
| logger: &Logger, | |||
| max_spec_version: semver::Version, | |||
There was a problem hiding this comment.
Adding this is actually unrelated to this PR, it's just improving the tests to no need the GRAPH_MAX_SPEC_VERSION env var set which was introduced in #2682.
| pub enum BlockchainKind { | ||
| /// Ethereum itself or chains that are compatible. | ||
| Ethereum, | ||
| } | ||
|
|
||
| impl fmt::Display for BlockchainKind { | ||
| fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { | ||
| let value = match self { | ||
| BlockchainKind::Ethereum => "ethereum", | ||
| }; | ||
| write!(f, "{}", value) | ||
| } | ||
| } | ||
|
|
||
| impl FromStr for BlockchainKind { | ||
| type Err = Error; | ||
|
|
||
| fn from_str(s: &str) -> Result<Self, Self::Err> { | ||
| match s { | ||
| "ethereum" => Ok(BlockchainKind::Ethereum), | ||
| _ => Err(anyhow!("unknown blockchain kind {}", s)), | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
How do you feel about delegating this to serde::plain, just like we did for subgraph features?
While the current implementation works flawlessly, if we use serde here we wouldn't need to write any more code when introducing new variants.
There was a problem hiding this comment.
I don't have much of a preference so I'll keep it as it is.
| (None, "subgraphFeatures") => { | ||
| graph::block_on(self.resolve_subgraph_features(arguments)) | ||
| } |
This introduces the
BlockchainMapin whichBlockchaininstances are stored, keyed by theirBlockchainKindand network. This is used in the entry points that need to call functions which are generic onC: Blockchain, which are:InstanceManager::start_subgraph,SubgraphRegistrar::create_subgraphandIndexNodeResolver::resolve_subgraph_features.Part of #2732.