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
{{ message }}
Repository navigation
Enhance udf to take additional non-expr arguments #822
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
There are some cases where you would like to pass additional data to a UDF that are not expressions. For example, suppose you wrote a UDF that did some kind of lookup and the function had a signature like
It would be convenient to allow for passing in arbitrary data.
Describe the solution you'd like
Most likely this would mean a change to PyScalarUDF::__call__ and I could see changing the function definition to something like fn __call__(&self, args: Vec<PyAny>) -> PyResult<PyExpr>. It's not immediately obvious to me how to set additional parameters, but it may mean switching from SimpleScalarUDF to a different ScalarUDFImpl to carry the additional data.
Describe alternatives you've considered
Right now you would need to do one of these approaches
create a class that you can set these values on and then use the __call__ function as your UDF
take advantage of setting the variable scope for lookup_values
After some initial investigation, the way the window functions are using an instance has a problem in that when the instance is reused it's carrying over the past state. I bet that's why the aggregate functions were set up to use a class type and then instantiate them in to_rust_accumulator. I'm trying to understand why this does work because it seems like the only place we instantiate is during the create_udaf however we're clearly getting two calls to __init__ in the unit test when I add a second aggregation in the same test using the same udf. This requires further investigation.
Activity
timsaucer commentedon Sep 22, 2024
This was implemented in #880 for window functions, just need to add it in for UDAF/UDF
timsaucer commentedon Sep 30, 2024
After some initial investigation, the way the window functions are using an instance has a problem in that when the instance is reused it's carrying over the past state. I bet that's why the aggregate functions were set up to use a class type and then instantiate them in
to_rust_accumulator. I'm trying to understand why this does work because it seems like the only place we instantiate is during thecreate_udafhowever we're clearly getting two calls to__init__in the unit test when I add a second aggregation in the same test using the same udf. This requires further investigation.Michael-J-Ward commentedon Oct 3, 2024
Did you figure out the double calls to
__init__?Was it because
to_rust_accumulatorcreates a factory that is invoked each time theudafis used in a query?