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

SQL: Fix issue with complex HAVING and GROUP BY ordinal #36594

Merged
merged 4 commits into from Dec 17, 2018

Conversation

matriv
Copy link
Contributor

@matriv matriv commented Dec 13, 2018

When trying to analyze a HAVING condition, we crate a temp Aggregate
Plan which wasn't created correctly (missing the expressions from the
SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY
couldn't be resolved correctly.

Also after successfully analyzing the HAVING condition, still the
original plan was returned.

Fixes: #36059

@matriv matriv added WIP :Analytics/SQL SQL querying labels Dec 13, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

When trying to analyze a HAVING condition, we crate a temp Aggregate
Plan which wasn't created correctly (missing the expressions from the
SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY
couldn't be resolved correctly.

Also after successfully analyzing the HAVING condition, still the
original plan was returned.

Fixes: elastic#36059
@matriv matriv changed the title SQL: WIP SQL: Fix issue with complex HAVING and GROUP BY ordinal Dec 13, 2018
@costin
Copy link
Member

costin commented Dec 13, 2018

Maybe add a description of the approach taken and what failed ?

Copy link
Member

@costin costin left a comment

Choose a reason for hiding this comment

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

LGTM.

@@ -152,6 +152,9 @@ protected ExecutionInfo executeWithInfo(TreeType plan) {
batchRuns++;

for (Rule<?, TreeType> rule : batch.rules) {
if (log.isTraceEnabled()) {
log.trace("Trying to apply rule {}", rule);
Copy link
Member

Choose a reason for hiding this comment

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

"About to apply rule" - trying implies that it might not be applied.

Copy link
Contributor Author

@matriv matriv Dec 14, 2018

Choose a reason for hiding this comment

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

Which can be the case... But anyway I prefer the "About to apply rule", thx.

Copy link
Contributor

@astefan astefan left a comment

Choose a reason for hiding this comment

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

LGTM. Left two comments

@@ -209,7 +209,7 @@ public void testGroupByOrderByScalarOverNonGrouped_WithHaving() {
}

public void testGroupByHavingNonGrouped() {
assertEquals("1:48: Cannot filter by non-grouped column [int], expected [text]",
assertEquals("1:48: Cannot filter HAVING on non-aggregate [int]; consider using WHERE instead",
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we losing here the text proposal? Can we still have it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thx for catching it, I had it in mind but forgot to open a relevant issue for that.
Here it is: #36693

@@ -396,6 +390,21 @@ public void testTranslateMathFunction_HavingClause_Painless() {
assertThat(aggFilter.scriptTemplate().params().toString(), endsWith(", {v=10}]"));
}

public void testGroupByAndHavingWithFunctionOnTopOfAggregation() {
LogicalPlan p = plan("SELECT keyword, max(int) FROM test GROUP BY 1 HAVING " + "abs(max(int)) > 10");
Copy link
Contributor

Choose a reason for hiding this comment

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

HAVING " + "abs(max(int)) - one String only, no need to split it in half.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep, was some leftover

@matriv matriv merged commit c086639 into elastic:master Dec 17, 2018
@matriv matriv deleted the mt/fix-36059 branch December 17, 2018 09:05
matriv added a commit that referenced this pull request Dec 17, 2018
When trying to analyse a HAVING condition, we crate a temp Aggregate
Plan which wasn't created correctly (missing the expressions from the
SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY
couldn't be resolved correctly.

Also after successfully analysing the HAVING condition, still the
original plan was returned.

Fixes: #36059
@matriv
Copy link
Contributor Author

matriv commented Dec 17, 2018

Backported to 6.x with 2c3484a

matriv added a commit that referenced this pull request Dec 17, 2018
When trying to analyse a HAVING condition, we crate a temp Aggregate
Plan which wasn't created correctly (missing the expressions from the
SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY
couldn't be resolved correctly.

Also after successfully analysing the HAVING condition, still the
original plan was returned.

Fixes: #36059
@matriv
Copy link
Contributor Author

matriv commented Dec 17, 2018

Backported to 6.5 with dead7c6

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

Successfully merging this pull request may close these issues.

SQL: GroupBy with ordinal returns an error
5 participants