Repository navigation
chore: Move AggregateExec optimizer utilities to a new file - #26733
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 |
| } | ||
|
|
||
| /// Finds the DataType and SortDirection for this Aggregate, if there is one | ||
| pub(super) fn get_minmax_desc(&self) -> Option<(FieldRef, bool)> { |
There was a problem hiding this comment.
These three helpers (get_minmax_desc, is_unordered_unfiltered_group_by_distinct, and topk_types_supported) were public in 55.1.0. Making them private breaks downstream callers, should we use #[doc(hidden)].
Could we retain deprecated public wrappers, or document the removals and migration path in the 56.0.0 upgrade guide?
There was a problem hiding this comment.
+1 for using #[doc(hidden)] rather than changing visibility in a minor release.
There was a problem hiding this comment.
Thanks for the review, addressed. (use #[doc(hidden)] instead of removing pub)
Those 3 APIs are special cases. I think a more accurate description is "made public by mistake": they were made public for internal optimizer use, but they don't actually need to be public.
However, it's possible (though unlikely) that downstream users already depend on them, so I agree we should mark them as #[doc(hidden)] first, and try to make them private after another release.
Important
Fork CI setup: For pull requests from a fork to
main, enable workflows in your fork's Actions tab before you push.See the fork CI setup guide.
Which issue does this PR close?
Rationale for this change
physical-plan/src/aggregates/mod.rshas 4k LoC, excluding tests.This PR tries to split out optimizer utilities that transforms
AggregateExec.What changes are included in this PR?
Commit 2 marks several
pubwith internal-only, see this doc for the reasons:https://datafusion.apache.org/contributor-guide/api-health.html#datafusion-internal-public-apis
The optimizer utilities on AggregateExec are standard internal-public APIs, as optimizers have strict invariants to follow to use them correctly, they're not intended to become public API. (some no longer need to be pub for the same reason)
What is the testing strategy for this PR?
existing tests
Are there any user-facing changes?
Yes, see above rationale.
Though, technically those hidden APIs are still accessible by downstream, but this PR adds markers to clarify its purpose.