minor: make HigherOrderSignature less error-prone#22106
Conversation
|
Thank you for opening this pull request! Reviewer note: cargo-semver-checks reported the current version number is not SemVer-compatible with the changes in this pull request (compared against the base branch). Details |
| /// # Return value | ||
| /// A Vec with the same number of [ValueOrLambda::Value] in `fields`. DataFusion will `CAST` the | ||
| /// function call arguments to these specific types. | ||
| /// |
There was a problem hiding this comment.
Should this be updated now?
There was a problem hiding this comment.
Small docs nit: this still describes lambda output coercion as being defined by the signature, but this PR now makes coerce_values_for_lambdas opt in by returning Some(...).
Could you update this and the sibling comment above value_fields_with_higher_order_udf to mention that the method is called and may return None? That would keep the public API docs aligned with the new invariant.
There was a problem hiding this comment.
Thanks @kosiew, missed that one ba11072
Just to make sure, I realized the old value_fields_with_higher_order_udf docs were imprecise, it should have been "Note this does not invokes coerce_values_for_lambdas even if requested by the function signature", so even with the new API, value_fields_with_higher_order_udf still doesn't call coerce_values_for_lambdas because it's used when lambdas output field aren't know yet
| /// ])?; | ||
| /// | ||
| /// assert_eq!( | ||
| /// coerce_to, |
There was a problem hiding this comment.
This still asserts a bare Vec<DataType>, but coerce_values_for_lambdas now returns Result<Option<Vec<DataType>>>.
Could you change the expected value to Some(vec![...]) so readers copying the example see the current API shape?
|
Since there are semver breaks, let's wait for a PMC to review and if proceed, decide when to merge this. cc @alamb |
|
Thanks @kosiew, I don't mind waiting for the review, but just to clarify, this actually changes only unreleased items, so there will be no public break (I believe the semver util checks only against main and doesn't take into account the last release) |
|
@gstvg Did some checking and semver bot compares against base branch main, not the latest release tag. The removed HigherOrderSignature members were introduced after 53.1.0, so this is an unreleased-main break, not a released API break. |
|
@LiaCastaneda does this look good to you? |
|
Hey, sorry for the inactivity -- I’ve been out for the last two weeks. I’ll review this today! |
No identified correctness issues. Proceeding to merge. |
|
Thanks @kumarUjjawal @kosiew and @LiaCastaneda for the review |
|
@gstvg |
…lify_coerce_values_for_lambdas_usage
6327212 to
4152b17
Compare
|
Thanks for the heads-up @kosiew, It's resolved now |
Which issue does this PR close?
Follow up of #21679
Rationale for this change
As noted by @LiaCastaneda in #21679 (comment), the higher-order signature can be made less error prone by removing the need to set the
coerce_values_for_lambdasfield whencoerce_values_for_lambdasshould be calledWhat changes are included in this PR?
Remove
HigherOrderSignature.coerce_values_for_lambdas/with_coerce_values_for_lambdasand modifyHigherOrderUDF::coerce_values_for_lambdasreturn fromResult<Vec<DataType>>toResult<Option<Vec<DataType>>>, and it's default implementation which now returnsOk(None)instead of an errorAre these changes tested?
Existing test cover the change
Are there any user-facing changes?
To unreleased items only