You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, one can specify params for a module at a global level in a substreams.yaml file. Like in this manifest, I'm filtering Transfer events using the ethereum_common:filtered_events imported module:
Now, I want to build another substream that uses the store_erc20_tokens store and also wants to filter on the PoolCreated event on UniswapV3Factory contract. For that, I will need a manifest like this:
The issue here is that the uniswap_v3_pool_tokens substream overrides the params even for the erc20 substream, resulting in wrong output from the store_erc20_tokens store.
My proposal here is that it should be allowed to specify params at the level of a consumer module so that this use case can work as intended. Eg:
Hi @abourget, the absence of this feature seriously limits the reuse of the substreams cache. Because of this, I always end up using ethereum_common:all_events and filter things manually every time instead of just using the ethereum_common:filtered_events with a param. If it was possible to use the ethereum_common:filtered_events multiple time with different params in the same substream, then I would be able to reuse a lot of substreams cache instead of running computations everytime from scratch.
Right now, one can specify params for a module at a global level in a
substreams.yaml
file. Like in this manifest, I'm filteringTransfer
events using theethereum_common:filtered_events
imported module:Now, I want to build another substream that uses the
store_erc20_tokens
store and also wants to filter on thePoolCreated
event onUniswapV3Factory
contract. For that, I will need a manifest like this:The issue here is that the
uniswap_v3_pool_tokens
substream overrides the params even for theerc20
substream, resulting in wrong output from thestore_erc20_tokens
store.My proposal here is that it should be allowed to specify params at the level of a consumer module so that this use case can work as intended. Eg:
This way, a set of independent params can be applied to a source module when it's being used by multiple consumer modules.
The text was updated successfully, but these errors were encountered: