Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-42746][SQL][FOLLOWUP] Improve the code for SupportsOrderingWithinGroup and Mode #49907

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

beliefer
Copy link
Contributor

What changes were proposed in this pull request?

This PR propose to improve the code for SupportsOrderingWithinGroup and Mode

Why are the changes needed?

First, we can simplify the code by given the default value to SupportsOrderingWithinGroup.
Second, Correct the comments style.

Does this PR introduce any user-facing change?

'No'.
New feature.

How was this patch tested?

GA.

Was this patch authored or co-authored using generative AI tooling?

'No'.

@github-actions github-actions bot added the SQL label Feb 12, 2025
Copy link
Member

@dongjoon-hyun dongjoon-hyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -390,10 +390,6 @@ case class PercentileCont(left: Expression, right: Expression, reverse: Boolean
override protected def withNewChildrenInternal(
newLeft: Expression, newRight: Expression): PercentileCont =
this.copy(left = newLeft, right = newRight)

override def orderingFilled: Boolean = left != UnresolvedWithinGroup
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is always false now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we make such a change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before the PR #48748, the default value is false.
That is a change not necessary!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why it's not necessary? orderingFilled should be true if UnresolvedWithinGroup is resolved and replaced?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the left should be always UnresolvedWithinGroup with PercentileContBuilder.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the previous version is better as we don't need this hidden assumption. I also don't think this PR improves the code, as requiring the implementation to implement these method can force them to think about the semantic.

Comment on lines 28 to +44
/** Indicator that ordering was set. */
def orderingFilled: Boolean
def orderingFilled: Boolean = false

/**
* Tells Analyzer that WITHIN GROUP (ORDER BY ...) is mandatory for function.
*
* @see [[QueryCompilationErrors.functionMissingWithinGroupError]]
*/
def isOrderingMandatory: Boolean
def isOrderingMandatory: Boolean = true

/**
* Tells Analyzer that DISTINCT is supported.
* The DISTINCT can conflict with order so some functions can ban it.
*
* @see [[QueryCompilationErrors.functionMissingWithinGroupError]]
* @see [[QueryCompilationErrors.distinctWithOrderingFunctionUnsupportedError]]
*/
def isDistinctSupported: Boolean
def isDistinctSupported: Boolean = false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the idea of default flags in this trait. I think every developer should make a deliberate decision about what behavior he wants for a new function. With default values, it's easy to forget some corner cases.

Personally, as a new contributor, I saw abstract/non-implemented methods and flags as hints, which is not to forget. But about default values, you can get to know them only by reading all the code or during testing.

@cloud-fan, what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants