Skip to content

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 requested review from astefan and costin December 13, 2018 13:33
@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.


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


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

}

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