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

Add build() method to SortBuilder implementations #17146

Merged
merged 5 commits into from
Mar 22, 2016

Conversation

cbuescher
Copy link
Member

For the current refactoring of SortBuilders related to #10217,
each SortBuilder should get a build() method that produces a
SortField according to the SortBuilder parameters on the shard.

This change also slightly refactors the current parse method in
SortParseElement to extract an internal parse method that returns
a list of sort fields only needs a QueryShardContext as input
instead of a full SearchContext. This allows using this internal
parse method for testing.

For the current refactoring of SortBuilders related to elastic#10217,
each SortBuilder should get a build() method that produces a
SortField according to the SortBuilder parameters on the shard.

This change also slightly refactors the current parse method in
SortParseElement to extract an internal parse method that returns
a list of sort fields only needs a QueryShardContext as input
instead of a full SearchContext. This allows using this internal
parse method for testing.
@cbuescher
Copy link
Member Author

@MaineC could you take a look at this? The generic test added to AbstractSortTestCase doesn't do many assertions on the two SortFields it compares, maybe you have an idea how to add to those tests. Also, those tests will be temporary and will be obsolete once we remove the old SortParseElement.

throw new QueryShardException(context, "Sorting not supported for field[" + fieldName + "]");
}

// Enable when we also know how to detect fields that do tokenize, but only emit one token
Copy link

Choose a reason for hiding this comment

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

Instead of having code commented out here - would it be better to track that in some follow up issue? (I know the comment was there before the refactoring, but code that's commented out always smells strange IMHO)

Copy link
Member Author

Choose a reason for hiding this comment

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

Just talked to @martijnvg, this is old code and can be removed.

@MaineC
Copy link

MaineC commented Mar 17, 2016

Overall looks awesome!

Left a few minor comments and questions.

About testing: I'm not sure we can test a whole lot more without knowing which type of sort we are dealing with. One idea (that would also be valid after removing the old parsing code) would be to add tests to the individual builders that have a few deeper assertions.

With this change it should already be possible to parse more than one sort element, no? This could be an addition to the tests.

@cbuescher
Copy link
Member Author

@MaineC thanks, I adressed most of your comments, still need to look into the Median-SortMode support and maybe open an issue about sorting with missing values.

About testing: I'm not sure we can test a whole lot more without knowing which type of sort we are dealing with. One idea (that would also be valid after removing the old parsing code) would be to add tests to the individual builders that have a few deeper assertions.

I will see if we can add a "assertSortField" method to each individual test that does some more inspection, maybe that works

With this change it should already be possible to parse more than one sort element, no? This could be an addition to the tests.

No, the SortParseElement will parse a whole "sort" : { } block but the builders themselves currently only represent one sort option of which we can have many. This parsing / building needs to go somewhere up into the abstract SortBuilder or somewhere else I think. But I'd say that is a follow up PR.

Also adding checks for median SortMode on non-numeric field types
to FieldSortBuilder, removing some unused code and switching
GeoDistanceSortBuilder to using ParseField.
@cbuescher
Copy link
Member Author

@MaineC I also adressed the rest of your comments, can you take another look if this looks good now?

@MaineC
Copy link

MaineC commented Mar 22, 2016

Looked over your changes and the comments you added - LGTM

@cbuescher
Copy link
Member Author

@MaineC thanks, I needed to move over few more lines from NestedInnerQueryParseSupport to the part in SortBuilder that is building the nested filters. I added those and merged in master once again.

cbuescher added a commit that referenced this pull request Mar 22, 2016
For the refactoring of SortBuilders related to #10217, each SortBuilder needs to get a build()
method that produces a SortField according to the SortBuilder parameters on the shard.
@cbuescher cbuescher merged commit 14f45c1 into elastic:master Mar 22, 2016
@clintongormley clintongormley added :Search/Search Search-related issues that do not fall into other categories and removed :Search Refactoring labels Feb 14, 2018
@cbuescher cbuescher deleted the sort-add-build branch March 20, 2024 20:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search/Search Search-related issues that do not fall into other categories v5.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants