-
Notifications
You must be signed in to change notification settings - Fork 25.3k
[Query rules] Add exclude
query rule type
#111420
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
Conversation
Hi @kderusso, I've created a changelog YAML for you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved out of PinnedQueryBuilder
without additional change.
10bc011
to
d63b5e3
Compare
315df19
to
dc7186c
Compare
Pinging @elastic/search-relevance (Team:Search - Relevance) |
Pinging @elastic/ent-search-eng (Team:SearchOrg) |
@@ -102,9 +105,9 @@ If multiple matching rules pin more than 100 documents, only the first 100 docum | |||
[[put-query-rule-example]] | |||
==== {api-examples-title} | |||
|
|||
The following example creates a new query rule with the ID `my-rule1` in a query ruleset called `my-ruleset`. | |||
The following example creates a new query rule in a query ruleset called `my-ruleset`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still mention something regarding my-rule1
and where that comes from (I assume it's an arbitrary ID for the name of the rule within the my-ruleset
ruleset?)
Only one of `ids` or `docs` may be specified, and at least one must be specified. | ||
- `docs` (Optional, array of objects) The documents to pin. | ||
- `docs` (Optional, array of objects) The specified documents. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the max # of documents always hardcoded to 100? If so, I'd mention that here too
throw new ElasticsearchParseException("pinned hits cannot exceed " + MAX_NUM_PINNED_HITS); | ||
throw new ElasticsearchParseException(type + " query rule actions cannot be empty"); | ||
} else if (((List<?>) action).size() > MAX_NUM_DOCS_IN_RULE) { | ||
throw new ElasticsearchParseException(type + " documents cannot exceed " + MAX_NUM_DOCS_IN_RULE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might it be worth also validating to ensure the doc IDs are all unique in the list? Or, keep that onus on the user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good callout. My only concern is that technically that might be considered a breaking change, because existing rulesets with duplicate rules could now break. We do dedup the rules later on when they are applied. I'm inclined to leave it as is just to avoid breaking existing rules, but let me know if you'd like to chat about this more.
@elasticmachine update branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Mostly small stuff, except I have a sneaking suspicion there's a bug with multiple exclude rules.
...lugin/ent-search/src/test/java/org/elasticsearch/xpack/application/rules/QueryRuleTests.java
Show resolved
Hide resolved
...iness-rules/src/main/java/org/elasticsearch/xpack/searchbusinessrules/SpecifiedDocument.java
Outdated
Show resolved
Hide resolved
...iness-rules/src/main/java/org/elasticsearch/xpack/searchbusinessrules/SpecifiedDocument.java
Outdated
Show resolved
Hide resolved
...ness-rules/src/main/java/org/elasticsearch/xpack/searchbusinessrules/PinnedQueryBuilder.java
Outdated
Show resolved
Hide resolved
.../rest/src/yamlRestTest/resources/rest-api-spec/test/entsearch/rules/40_rule_query_search.yml
Outdated
Show resolved
Hide resolved
@elasticmachine update branch |
...iness-rules/src/main/java/org/elasticsearch/xpack/searchbusinessrules/SpecifiedDocument.java
Show resolved
Hide resolved
x-pack/plugin/ent-search/src/main/java/org/elasticsearch/xpack/application/rules/QueryRule.java
Show resolved
Hide resolved
x-pack/plugin/ent-search/src/main/java/org/elasticsearch/xpack/application/rules/QueryRule.java
Outdated
Show resolved
Hide resolved
List<SpecifiedDocument> pinnedDocs = pinnedDocsSupplier != null ? pinnedDocsSupplier.get() : null; | ||
if (pinnedDocs != null && pinnedDocs.isEmpty() == false) { | ||
PinnedQueryBuilder pinnedQueryBuilder = new PinnedQueryBuilder(organicQuery, pinnedDocs.toArray(new SpecifiedDocument[0])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think I figured out the issue:
As of the rule query rename (#108831), RuleQueryBuilder
deserialization was changed to throw away pinnedIds
and pinnedDocs
values. If I'm reading the code correctly, I think BwC with 8.10.0 - 8.12.1 coordinator nodes was broken here, but it wasn't spotted at the time.
These changes further break BwC (although if you consider "broken" as a binary state, it was already broken) because pinnedDocsSupplier
will always be null
. The end effect is that any rule query from an 8.10.0 - 8.12.1 coordinator node will be handled as if none of the criteria matched (i.e. just run the organic query).
...gin/ent-search/src/main/java/org/elasticsearch/xpack/application/rules/RuleQueryBuilder.java
Show resolved
Hide resolved
...lugin/ent-search/src/test/java/org/elasticsearch/xpack/application/rules/QueryRuleTests.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple small follow-ups, plus maybe BwC is broken? Hope i'm wrong on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the iterations!
Adds a new type of query rule,
exclude
. Unlike thepinned
rule, which pins specified documents to the top of result sets, theexclude
query rule will identify documents that we never want returned in the result sets.Here's an example of a ruleset with both a
pinned
and anexclude
rule: