-
Notifications
You must be signed in to change notification settings - Fork 25.8k
Multi-level Nested Sort with Filters #26395
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
Allow multple levels of nested sorting where each level can have it's own filter. Backward compatible with previous single-level nested sort.
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
martijnvg
left a comment
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.
@mattweber This looks great and I like the new syntax for nested sorting! I left a few comments.
| // assertThat(searchResponse.getHits().getHits()[1].sortValues()[0].toString(), equalTo("-2")); | ||
| // assertThat(searchResponse.getHits().getHits()[2].getId(), equalTo("1")); | ||
| // assertThat(searchResponse.getHits().getHits()[2].sortValues()[0].toString(), equalTo("-1")); | ||
| assertThat(searchResponse.getHits().getHits()[0].getId(), equalTo("3")); |
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
| order = in.readOptionalWriteable(SortOrder::readFromStream); | ||
| sortMode = in.readOptionalWriteable(SortMode::readFromStream); | ||
| unmappedType = in.readOptionalString(); | ||
| if (in.getVersion().onOrAfter(Version.V_5_6_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.
5.6 and 6.0 branches are in feature freeze, so the next version this feature can be included would be 6.1
| existing sort options: | ||
| field support has a `nested` sort option with the following properties: | ||
|
|
||
| `nested_path`:: |
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.
The migration should document that nested_path and nested_filter are deprecated.
| PARSER.declareString(FieldSortBuilder::unmappedType , UNMAPPED_TYPE); | ||
| PARSER.declareString((b, v) -> b.order(SortOrder.fromString(v)) , ORDER_FIELD); | ||
| PARSER.declareString((b, v) -> b.sortMode(SortMode.fromString(v)), SORT_MODE); | ||
| PARSER.declareObject(FieldSortBuilder::setNestedFilter, (p, c) -> SortBuilder.parseNestedFilter(p), NESTED_FILTER_FIELD); |
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 think we should add some deprecation logging here too for the nested_filter and nested_path parameters.
private static final DeprecationLogger DEPRECATION_LOGGER = new DeprecationLogger(Loggers.getLogger(ParseField.class));
...
PARSER.declareString((fieldSortBuilder, nestedPath) -> {
DEPRECATION_LOGGER.deprecated("[nested_path] has been deprecated in favor of the [nested] parameter");
fieldSortBuilder.setNestedPath(nestedPath);
} , NESTED_PATH_FIELD);
...
PARSER.declareObject(FieldSortBuilder::setNestedFilter, (p, c) -> {
DEPRECATION_LOGGER.deprecated("[nested_filter] has been deprecated in favour for the [nested] parameter");
return SortBuilder.parseNestedFilter(p);}, NESTED_FILTER_FIELD);
...
|
test this please |
|
@martijnvg Thanks for the review! Thats a bummer about waiting for 6.1, I was hoping it could make a 5.x release since it is backward compatible. I have addressed your comments, please let me know if you would like any other changes. |
jpountz
left a comment
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.
Even thoug I think nested is often abused, I don't like the fact that queries and aggregations allow for multiple levels of nesting but sorting doesn't, so +1 to expose a way to make it work.
| assert rootDocs.get(rootDoc) : "can only sort root documents"; | ||
| assert rootDoc >= lastSeenRootDoc : "can only evaluate current and upcoming root docs"; | ||
| if (rootDoc == lastSeenRootDoc) { | ||
| return lastEmittedOrd != -1; |
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.
let's rename rootDoc and lastSeenRootDoc to parentDoc and lastSeenParentDoc in that file?
| PARSERS = unmodifiableMap(parsers); | ||
| } | ||
|
|
||
| public static class NestedSort implements Writeable, Reader<NestedSort>, ToXContentObject { |
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.
Even though it is not strictly a sort builder, can you rename it NestedSortBuilder for consistency and move it to its own class?
| private QueryBuilder filter; | ||
| private NestedSort nestedSort; | ||
|
|
||
| public NestedSort() { |
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.
should we requite the path in the constructor since it is mandatory?
|
Thanks @jpountz, I addressed your comments. How does this look? |
|
retest this please |
|
@mattweber Thanks for fixing the comments. The PR looks good! Only the build failed with checkstyle violations. Can you fix this? |
|
@martijnvg @jpountz Thank you for reviewing everything. Just pushed checkstyle and test fixes. I think this will do it. |
|
retest this please |
|
The mixed cluster test failures that occurred in the build this PR triggered are related to the fact that the changes aren't yet in the 6.x branch. This causes serialization errors when a 7.0.0-alph1 node reads the shard level search request from a 6.1.0-SNAPSHOT node. So I'll merge this change both to master and 6.x branches at the same time to minimize the regular builds from running into this failure. |
|
The versions and skips should be set so that they cause no failures, backported with version updates, then another commit to master moving the version to the 6.x version they are compatible with. |
|
Here's another PR where I expand on this strategy; this is the build-failure minimizing strategy, not merging as quickly as possible. Instead, we should take our time to get a green build on master, then backport (with the version bumps) and getting a green build again, and then a final commit to get the versions right still maintaining green status. |
|
@jasontedor Good point. I'll follow the same steps mentioned in that PR. |
|
I merged squashed the change into the master branch via 6377afa I'll backport this change to 6.x branch later today unless a build failure related to this change occurs. @mattweber Thanks for this contribution to nested sorting! |
|
I just realized that as part of the git merge (git merge --squash) that I became the author of this change :( |
|
@martijnvg For future reference, you can push commits to PRs so you could have pushed the version-changing commit to this PR, then merged from the GitHub UI (preserving @mattweber as the author). As far as correcting, I think that you can:
|
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
|
@mattweber Can you change the 6.1.0 version check to 7.0.0-alpha1? (as it turns out I can't make this change in your pr) After that I'll hit the squash and merge button and do they backporting to 6.x branch. |
|
@martijnvg I'm wondering whether that would work with the online editor, eg. https://github.com/mattweber/elasticsearch/edit/multi_nested_sort/core/src/main/java/org/elasticsearch/search/sort/FieldSortBuilder.java?pr=/elastic/elasticsearch/pull/26395 |
…til the change has been backported to 6.x branch.
…til the change has been backported to 6.x branch.
…til the change has been backported to 6.x branch.
|
retest this please |
|
@jpountz Your idea worked :) I'll squash and merge once the build is green. |
|
Wow lots going on. Thanks @martijnvg @jpountz @jasontedor! Let me know if you need me to do anything. |
Allow multiple levels of nested sorting where each level can have it's own filter. Backward compatible with previous single-level nested sort.
Allow multiple levels of nested sorting where each level can have it's own filter. This allows us to have complex nested sort criteria just like we have with queries and aggregations. This is backwards compatible with previous single-level nested sort.
@martijnvg @jpountz Can you please review?