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
See #836. Current web3 filter api's are not intuitive and are just unable to do certain things. An example is creating a filter for array event arguments. Current argument encoding can not differentiate between argument options and arguments that are arrays:
The following lines in web3/utils/events.py parse the above array incorrectly into argument options:
67 encoded_args = [
68 [
69 None if option is None else encode_hex(encode_single(arg['type'], option))
70 for option in arg_options]
71 -> for arg, arg_options in zipped_abi_and_args
72 ]
How can it be fixed?
Argument values to filter on should have abi type aware handling, so that the filter parameters can be validated, and array type arguments can be distinguished from lists of multiple match targets. A few ideas for how this could look:
Option 1. A filter argument type, that evaluates to the encoded topic or topics. Can
be supplied to the topic parameter list when creating an event filter.
What was wrong?
See #836. Current web3 filter api's are not intuitive and are just unable to do certain things. An example is creating a filter for array event arguments. Current argument encoding can not differentiate between argument options and arguments that are arrays:
Current api:
The following lines in web3/utils/events.py parse the above array incorrectly into argument options:
How can it be fixed?
Argument values to filter on should have abi type aware handling, so that the filter parameters can be validated, and array type arguments can be distinguished from lists of multiple match targets. A few ideas for how this could look:
Option 1. A filter argument type, that evaluates to the encoded topic or topics. Can
be supplied to the topic parameter list when creating an event filter.
Although this is a bit awkward, it is nice that the argument object could be immutable.
Option 2. The createFilter method to accept kwargs for event arguements
Single value:
Mutiple argument values:
I like this for its simplicity, although setting multiple values as lists still feels a bit unclear.
Option 3. A FilterParameters object that manages parameter checking, that gets passed into createFilter.
Accepting multiple values as method arguments makes the intention more readable, but having a mutable object manage the parameters is not ideal.
The text was updated successfully, but these errors were encountered: