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

QL: Verify filter's condition type #66268

Merged
merged 6 commits into from
Dec 15, 2020

Conversation

bpintea
Copy link
Contributor

@bpintea bpintea commented Dec 14, 2020

This adds a check in the verifier to check if filter's condition is of a
boolean type and fail the request otherwise.

Closes #66254.

This adds a check in the verifier to check if filter's condition is of a
boolean type and fail the request otherwise.
Make sure a fields's type is available before checking it's value.
@bpintea bpintea marked this pull request as ready for review December 14, 2020 16:53
@elasticmachine elasticmachine added the Team:QL (Deprecated) Meta label for query languages team label Dec 14, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-ql (Team:QL)

@bpintea bpintea requested review from costin, matriv, astefan and palesz and removed request for costin December 14, 2020 16:54
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.

Some minor adjustments required. Looks good otherwise.

@@ -626,6 +628,15 @@ private static boolean checkGroupMatch(Expression e, Node<?> source, List<Expres
return false;
}

private static void checkBooleanFiltering(LogicalPlan p, Set<Failure> localFailures) {
Copy link
Member

Choose a reason for hiding this comment

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

Filtering only works on bool hence why I recommend renaming it to checkFilterConditionType

private static void checkBooleanFiltering(LogicalPlan p, Set<Failure> localFailures) {
if (p instanceof Filter) {
Expression condition = ((Filter) p).condition();
if (condition.resolved() && condition.dataType() != BOOLEAN) {
Copy link
Member

Choose a reason for hiding this comment

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

No need to check if the condition is resolved, this has already been checked before - these checks get applied only if the plan is fully resolved.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, this follows after checking against unresolved nodes (and even a comment about it!). Thanks, fixed.

if (p instanceof Filter) {
Expression condition = ((Filter) p).condition();
if (condition.resolved() && condition.dataType() != BOOLEAN) {
localFailures.add(fail(condition, "Cannot filter by non-boolean expression of type [{}]", condition.dataType()));
Copy link
Member

Choose a reason for hiding this comment

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

Maybe Condition expression needs to be boolean, found [{}]. Remove the notion of filter which is not something the user declares.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed.

Copy link
Contributor

@palesz palesz left a comment

Choose a reason for hiding this comment

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

LGTM, one comment regarding testing.

@@ -326,6 +326,23 @@ Pettey
Heyers
;

iifConditionWhere
SELECT last_name FROM test_emp WHERE IIF(LENGTH(last_name) < 7, true, false) LIMIT 10;
Copy link
Contributor

Choose a reason for hiding this comment

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

👍 for this test case.
What about covering the simplest case (WHERE boolField) specifically too? The reason: the test case above gets translated into a script query, while the WHERE boolField into a terms query, and while there are plenty of test cases that test the script query, I don't think we have any that tests querying a bool field directly. Note: This would require adding a new field to the test dataset with bool type though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeh, I think it might make sense to add data for a new test index, with more types (like floats like bools) or extend one of the current ones. But not sure if part of this small PR. I'll open an issue to track it.

Copy link
Contributor

@palesz palesz left a comment

Choose a reason for hiding this comment

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

Green checkmark, since my previous comment should not be a blocker.

- remove superfluous resolution check.
- rename a method.
Move checkFilterConditionType() into it's own QL class, VerifierChecks.
Copy link
Contributor

@matriv matriv left a comment

Choose a reason for hiding this comment

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

LGTM

@bpintea
Copy link
Contributor Author

bpintea commented Dec 15, 2020

As @costin pointed out, this check should be extended to EQL as well, so the last commit does that.

The CI should fail until #66252 is merged in though, since with #65325 in place, an = TRUE is added irrespective of the FieldAttribute type (which is corrected by #66252) so any WHERE foo turns into WHERE foo = TRUE which is evaluated as a boolean, so this newly added check incorrectly passes -> turning it to a draft.

@bpintea
Copy link
Contributor Author

bpintea commented Dec 15, 2020

@elasticmachine update branch

@bpintea bpintea marked this pull request as ready for review December 15, 2020 15:37
@bpintea bpintea requested a review from costin December 15, 2020 15:37
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 2.

@bpintea bpintea merged commit 3aec1a3 into elastic:master Dec 15, 2020
@bpintea bpintea deleted the feat/verify_non_boolean_cond branch December 15, 2020 18:47
bpintea added a commit to bpintea/elasticsearch that referenced this pull request Dec 15, 2020
* Verify filter's condition type

This adds a check in the verifier to check if filter's condition is of a
boolean type and fail the request otherwise.

(cherry picked from commit 3aec1a3)
bpintea added a commit to bpintea/elasticsearch that referenced this pull request Dec 15, 2020
* Verify filter's condition type

This adds a check in the verifier to check if filter's condition is of a
boolean type and fail the request otherwise.

(cherry picked from commit 3aec1a3)
bpintea added a commit that referenced this pull request Dec 15, 2020
* SQL: Verify filter's condition type (#66268)

* Verify filter's condition type

This adds a check in the verifier to check if filter's condition is of a
boolean type and fail the request otherwise.

(cherry picked from commit 3aec1a3)
@bpintea bpintea changed the title SQL: Verify filter's condition type QL: Verify filter's condition type Dec 15, 2020
bpintea added a commit that referenced this pull request Dec 15, 2020
* SQL: Verify filter's condition type (#66268)

* Verify filter's condition type

This adds a check in the verifier to check if filter's condition is of a
boolean type and fail the request otherwise.

(cherry picked from commit 3aec1a3)
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.

QL: verify that filtering's condition is always valid
6 participants