Skip to content

Conversation

@mattweber
Copy link
Contributor

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?

Allow multple levels of nested sorting where each level
can have it's own filter.  Backward compatible with
previous single-level nested sort.
@elasticmachine
Copy link
Collaborator

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?

Copy link
Member

@martijnvg martijnvg left a 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"));
Copy link
Member

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)) {
Copy link
Member

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`::
Copy link
Member

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);
Copy link
Member

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);
...

@martijnvg martijnvg added :Search/Search Search-related issues that do not fall into other categories >feature v6.1.0 v7.0.0 :Nested Docs and removed :Search/Search Search-related issues that do not fall into other categories labels Aug 28, 2017
@martijnvg
Copy link
Member

test this please

@mattweber
Copy link
Contributor Author

@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.

Copy link
Contributor

@jpountz jpountz left a 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;
Copy link
Contributor

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 {
Copy link
Contributor

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() {
Copy link
Contributor

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?

@mattweber
Copy link
Contributor Author

Thanks @jpountz, I addressed your comments. How does this look?

@martijnvg
Copy link
Member

retest this please

@martijnvg
Copy link
Member

@mattweber Thanks for fixing the comments. The PR looks good! Only the build failed with checkstyle violations. Can you fix this?

@mattweber
Copy link
Contributor Author

@martijnvg @jpountz Thank you for reviewing everything. Just pushed checkstyle and test fixes. I think this will do it.

@martijnvg
Copy link
Member

retest this please

@martijnvg
Copy link
Member

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.

@jasontedor
Copy link
Member

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.

@jasontedor
Copy link
Member

jasontedor commented Aug 30, 2017

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.

@martijnvg
Copy link
Member

@jasontedor Good point. I'll follow the same steps mentioned in that PR.

@martijnvg
Copy link
Member

I merged squashed the change into the master branch via 6377afa
and set the version to 7.0.0-alph1 via 472a5dd

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!

@martijnvg
Copy link
Member

I just realized that as part of the git merge (git merge --squash) that I became the author of this change :(
Not sure what would be best to restore this mistake. (I can only think of reverting the commit and then commit it again with the @mattweber as author)

@jasontedor
Copy link
Member

@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:

  • revert the commits that you pushed to master
  • reopen this PR
  • push the version-changing commit to this PR
  • merge this PR from the GitHub UI

@martijnvg martijnvg reopened this Aug 30, 2017
@elasticmachine
Copy link
Collaborator

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
Copy link
Member

@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.

@jpountz
Copy link
Contributor

jpountz commented Aug 30, 2017

…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.
@martijnvg
Copy link
Member

retest this please

@martijnvg
Copy link
Member

@jpountz Your idea worked :)

I'll squash and merge once the build is green.

@mattweber
Copy link
Contributor Author

Wow lots going on. Thanks @martijnvg @jpountz @jasontedor! Let me know if you need me to do anything.

@martijnvg martijnvg merged commit 140395c into elastic:master Aug 30, 2017
martijnvg pushed a commit that referenced this pull request Aug 30, 2017
Allow multiple levels of nested sorting where each level can have it's own filter.
Backward compatible with previous single-level nested sort.
@martijnvg
Copy link
Member

backported to 6.x branch via: 2425da1 and 42c7745

Changed the version check in master via ea3fa76

@clintongormley clintongormley added :Search/Search Search-related issues that do not fall into other categories and removed :Nested Docs labels Feb 14, 2018
@jimczi jimczi added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>feature :Search/Search Search-related issues that do not fall into other categories v6.1.0 v7.0.0-beta1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants