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

Collect multiple paths from XContentMapValues #68540

Merged
merged 8 commits into from
Feb 11, 2021

Conversation

cbuescher
Copy link
Member

Currently, when a document source mixed json object and dotted syntax like e.g.
{ "foo" : { "bar" : 0 }, "foo.bar" : 1}, extracting the values from the source
map via XContentMapValues#extractValue returns after the first value for a path
has been found. Instead we should exhaust all possibilities and return a list of
objects of we find more than one value when extending the lookup path.

Closes #68215

Currently, when a document source mixed json object and dotted syntax like e.g.
{ "foo" : { "bar" : 0 }, "foo.bar" : 1}, extracting the values from the source
map via XContentMapValues#extractValue returns after the first value for a path
has been found. Instead we should exhaust all possibilities and return a list of
objects of we find more than one value when extending the lookup path.

Closes elastic#68215
@cbuescher cbuescher added >bug :Search/Mapping Index mappings, including merging and defining field types v8.0.0 v7.12.0 v7.11.1 labels Feb 4, 2021
@elasticmachine elasticmachine added the Team:Search Meta label for search team label Feb 4, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

@cbuescher
Copy link
Member Author

I think extractRawValues would use a similar treatment but wanted to ask about the differences in these two methods before going ahead and adding it. Can do so in this PR though when I understand the expectations better.

Copy link
Contributor

@romseygeek romseygeek left a comment

Choose a reason for hiding this comment

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

LGTM, thanks @cbuescher

try (XContentParser parser = createParser(JsonXContent.jsonXContent, Strings.toString(builder))) {
Map<String, Object> map = parser.map();
assertThat((List<?>) XContentMapValues.extractValue("foo.cat", map), containsInAnyOrder("meow", "miau"));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens if we have "foo.cat" : ["miaw", "purr"] here? I guess we get a List that contains a String and a further List, which is probably fine given that this is an edge case already.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. I think flattening out the list in this case makes sense and is doable. In the end we only need to handle single values and lists here. I added a commit along those lines and extended the test.

Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like it breaks a bunch of assumptions in tests - let's leave it as it was previously, with the mix of values? As I said, I think it's a sufficiently rare case that having an odd-looking response in fetch is fine.

Copy link
Member Author

Choose a reason for hiding this comment

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

Saw the tests, probably just a class cast issue that I overlooked. Will see how easy it is to fix

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, I can see how this gets tricky now, rolled back the last change. I added a test to the FieldFetcherTests though that shows that although we might return a List that contains a String and a further List in this case via XContentMapValues (which can even be considered to be correct, depending on the viewpoint), we unpack this e.g. when retrieving fields values to a simple list.

@cbuescher
Copy link
Member Author

@romseygeek thanks for the review, what do you think about my question above whether this addition should also happen in extractRawValues. I don't fully understand the different scenarios in which those two variations are used, thats why I left it out for now.

@romseygeek
Copy link
Contributor

I think extractRawValues would use a similar treatment but wanted to ask about the differences in these two methods before going ahead and adding i

extractRawValues already has this behaviour (see #65539)

Christoph Büscher added 2 commits February 10, 2021 12:56
Copy link
Contributor

@romseygeek romseygeek left a 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 @cbuescher

@cbuescher
Copy link
Member Author

@elasticmachine update branch

@cbuescher
Copy link
Member Author

@elasticmachine run elasticsearch-ci/bwc

1 similar comment
@cbuescher
Copy link
Member Author

@elasticmachine run elasticsearch-ci/bwc

@cbuescher
Copy link
Member Author

@elasticmachine update branch

@cbuescher cbuescher merged commit c4a1dfc into elastic:master Feb 11, 2021
cbuescher pushed a commit that referenced this pull request Feb 11, 2021
Currently, when a document source mixed json object and dotted syntax like e.g.
{ "foo" : { "bar" : 0 }, "foo.bar" : 1}, extracting the values from the source
map via XContentMapValues#extractValue returns after the first value for a path
has been found. Instead we should exhaust all possibilities and return a list of
objects of we find more than one value when extending the lookup path.

Closes #68215
cbuescher pushed a commit that referenced this pull request Feb 11, 2021
Currently, when a document source mixed json object and dotted syntax like e.g.
{ "foo" : { "bar" : 0 }, "foo.bar" : 1}, extracting the values from the source
map via XContentMapValues#extractValue returns after the first value for a path
has been found. Instead we should exhaust all possibilities and return a list of
objects of we find more than one value when extending the lookup path.

Closes #68215
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this pull request Feb 11, 2021
This change adds tests around the handling of mixed object and dot notation in
document source when using the `fields` API with nested fields left out
of elastic#67432. After merging elastic#68540, this test can now be added.

Relates to elastic#67432
cbuescher pushed a commit that referenced this pull request Feb 11, 2021
This change adds tests around the handling of mixed object and dot notation in
document source when using the `fields` API with nested fields left out
of #67432. After merging #68540, this test can now be added.

Relates to #67432
cbuescher pushed a commit that referenced this pull request Feb 11, 2021
This change adds tests around the handling of mixed object and dot notation in
document source when using the `fields` API with nested fields left out
of #67432. After merging #68540, this test can now be added.

Relates to #67432
easyice pushed a commit to easyice/elasticsearch that referenced this pull request Mar 25, 2021
Currently, when a document source mixed json object and dotted syntax like e.g.
{ "foo" : { "bar" : 0 }, "foo.bar" : 1}, extracting the values from the source
map via XContentMapValues#extractValue returns after the first value for a path
has been found. Instead we should exhaust all possibilities and return a list of
objects of we find more than one value when extending the lookup path.

Closes elastic#68215
easyice pushed a commit to easyice/elasticsearch that referenced this pull request Mar 25, 2021
This change adds tests around the handling of mixed object and dot notation in
document source when using the `fields` API with nested fields left out
of elastic#67432. After merging elastic#68540, this test can now be added.

Relates to elastic#67432
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search/Mapping Index mappings, including merging and defining field types Team:Search Meta label for search team v7.11.2 v7.12.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Strange behaviour of fields API with mixed object notation
5 participants