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

Relevance Field Validation for single-field Relevance Functions #186

Conversation

forestmvey
Copy link

@forestmvey forestmvey commented Dec 9, 2022

Description

Handle fields validation for single-field relevance functions. Treating field argument as qualified name we can validate as an identifier. This does remove some tests as the type is now interpreted as identifier. Removed tests should be inconsequential as their coverage is done through the V2 parser and now fields identifier validation. Field parameter can be quoted or unquoted and both will be treated as qualified names.

Example Queries

select * from stackexchange_beer where match(invalid, 'beer');
select * from stackexchange_beer where match_bool_prefix(invalid, 'beer');
select * from stackexchange_beer where match_phrase(invalid, 'beer');
select * from stackexchange_beer where match_phrase_prefix(invalid, 'beer');

Issues Resolved

Issue: 613

Check List

  • New functionality includes testing.
    • All tests pass, including unit test, integration test and doctest
  • New functionality has been documented.
    • New functionality has javadoc added
    • New functionality has user manual doc added
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@forestmvey forestmvey requested a review from a team December 9, 2022 00:50
@codecov
Copy link

codecov bot commented Dec 9, 2022

Codecov Report

Merging #186 (534f52b) into integ-relevance-fields-validation (2af7321) will decrease coverage by 2.50%.
The diff coverage is 100.00%.

@@                           Coverage Diff                           @@
##             integ-relevance-fields-validation     #186      +/-   ##
=======================================================================
- Coverage                                98.30%   95.80%   -2.51%     
+ Complexity                                3518     3517       -1     
=======================================================================
  Files                                      342      352      +10     
  Lines                                     8694     9348     +654     
  Branches                                   554      672     +118     
=======================================================================
+ Hits                                      8547     8956     +409     
- Misses                                     142      334     +192     
- Partials                                     5       58      +53     
Flag Coverage Δ
query-workbench 62.76% <ø> (?)
sql-engine 98.30% <100.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...expression/function/RelevanceFunctionResolver.java 100.00% <ø> (ø)
...h/sql/expression/function/OpenSearchFunctions.java 100.00% <100.00%> (ø)
...ript/filter/lucene/relevance/SingleFieldQuery.java 100.00% <100.00%> (ø)
...pensearch/sql/ppl/parser/AstExpressionBuilder.java 100.00% <100.00%> (ø)
...pensearch/sql/sql/parser/AstExpressionBuilder.java 100.00% <100.00%> (ø)
...ch/public/components/QueryResults/QueryResults.tsx 61.60% <0.00%> (ø)
...h/public/components/QueryLanguageSwitch/Switch.tsx 85.71% <0.00%> (ø)
workbench/public/components/SQLPage/SQLPage.tsx 100.00% <0.00%> (ø)
workbench/public/utils/PanelWrapper.tsx 100.00% <0.00%> (ø)
workbench/public/components/PPLPage/PPLPage.tsx 56.52% <0.00%> (ø)
... and 5 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@forestmvey forestmvey force-pushed the draft-relevance-fields-validation branch from e32b733 to f292f81 Compare December 9, 2022 17:02
@forestmvey forestmvey force-pushed the draft-relevance-fields-validation branch from f292f81 to 2d25614 Compare December 9, 2022 17:15
@forestmvey forestmvey changed the title Draft relevance fields validation [DRAFT] Relevance Field Validation for single-field Relevance Functions Dec 9, 2022
@@ -431,7 +435,8 @@ void should_build_match_phrase_query_with_default_parameters() {
+ "}",
buildQuery(
DSL.match_phrase(
DSL.namedArgument("field", literal("message")),
DSL.namedArgument("field",
new ReferenceExpression("message", OPENSEARCH_TEXT_KEYWORD)),

Choose a reason for hiding this comment

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

Try different types in all tests, just for fun.

@forestmvey forestmvey marked this pull request as ready for review December 12, 2022 23:56
@forestmvey forestmvey changed the title [DRAFT] Relevance Field Validation for single-field Relevance Functions Relevance Field Validation for single-field Relevance Functions Dec 13, 2022
@acarbonetto
Copy link

Field parameter can be quoted or unquoted and both will be treated as qualified names.

Do you mean with backticks?

@@ -475,7 +475,7 @@ private List<UnresolvedExpression> singleFieldRelevanceArguments(
// to skip environment resolving and function signature resolving
ImmutableList.Builder<UnresolvedExpression> builder = ImmutableList.builder();
builder.add(new UnresolvedArgument("field",
new Literal(StringUtils.unquoteText(ctx.field.getText()), DataType.STRING)));
new QualifiedName(StringUtils.unquoteText(ctx.field.getText()))));

Choose a reason for hiding this comment

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

this should work for string literals as well as qualifiednames

Copy link
Author

Choose a reason for hiding this comment

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

Works for both string literals and qualifiedNames. The relevanceField is treated as a QualifiedName in the AstExpressionBuilder and later in the Analyzer can be visited as a QualifiedName.

@@ -463,7 +463,7 @@ public void filteredDistinctCount() {
public void matchPhraseQueryAllParameters() {
assertEquals(
AstDSL.function("matchphrasequery",
unresolvedArg("field", stringLiteral("test")),
unresolvedArg("field", qualifiedName("test")),

Choose a reason for hiding this comment

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

this should work for string literals as well as qualifiednames
we should test both, right?

@@ -36,6 +37,18 @@ public void match_in_having() throws IOException {
verifyDataRows(result, rows("Bates"));
}

@Test
public void missing_field_test() {

Choose a reason for hiding this comment

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

include test with backticks -> SemanticCheckException
include test with quotes -> no error

@forestmvey
Copy link
Author

Field parameter can be quoted or unquoted and both will be treated as qualified names.

Do you mean with backticks?

backticks are supported as well!

Copy link

@MaxKsyunz MaxKsyunz left a comment

Choose a reason for hiding this comment

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

LGTM!

…ance function field parameters.

Signed-off-by: forestmvey <[email protected]>
@forestmvey forestmvey force-pushed the draft-relevance-fields-validation branch from cfd3144 to 534f52b Compare December 15, 2022 23:40
@forestmvey forestmvey closed this Dec 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants