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
hi @BeJF good question. Filtering isn't yet implemented. As you mention, the idea is that each reducer will contain its own filtering logic (as opposed to one single filter step for the whole pipeline). The goal is to make each reducer as standalone as possible, with room for custom filters that are particular to the data structure of each collection.
Now, where should we add the code within the reducer? That's not strictly defined. Personally, I would add include a new function that gets called as a predicate from the iteration that happens inside the reduce_byron/alonzo_tx).
Any configurable options (eg: which addresses to filter by) should be added to the serializable Config struct of the reducer. This will make the options available to be entered in the toml file.
Is this something you would like code yourself? PRs are very welcome!
Hello,
As per the documentation, there is a todo "Document filtering options per collection".
I had a look at the code and from what I understood, it doesn't seem like address filtering is already implemented for that Reducer.
The relevant steps I identified where it could have been implemented are when:
I saw nothing like an address filtering in that part of the code. The questions are then:
=> Is it implemented and I'm not looking at it the right way OR it is not implemented yet and you already have an idea of how it could be?
The text was updated successfully, but these errors were encountered: