-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Fields API won't extract field that begins with the name of an object #65499
Comments
Pinging @elastic/es-search (Team:Search) |
@romseygeek do you think this might be something you can have a look at? I think you are started to get pretty into how we extract values from xcontent. |
Looks like we don't correctly handle object paths in field fetcher (this fails in the same way if you remove the |
Oh! I thought I saw it working locally. I guess I missed it. |
Ignore my last comment, it does indeed only fail with the extra section. It's a bug in |
When we have an object that looks like this: ``` { "foo" : { "cat": "meow" }, "foo.bar" : "baz" ``` where the inner objects of foo are defined both as json objects and via dot notation, then XContentMapValues.extractValue() will only descend through the json object and will not collect values from the dot notated paths. In these cases, the foo.bar values will not be returned in the fields section of a search response. This commit adds the ability to check both paths, ensuring that all relevant values get returned as part of fields. Fixes #65499
When we have an object that looks like this: ``` { "foo" : { "cat": "meow" }, "foo.bar" : "baz" ``` where the inner objects of foo are defined both as json objects and via dot notation, then XContentMapValues.extractValue() will only descend through the json object and will not collect values from the dot notated paths. In these cases, the foo.bar values will not be returned in the fields section of a search response. This commit adds the ability to check both paths, ensuring that all relevant values get returned as part of fields. Fixes #65499
Check it out:
Makes this:
Notice no
fields
in the response. This seems to be because we found thefoo
object and didn't findbar
inside it. I'm not sure though. It seems like we should findfoo.bar
.These kinds of documents are confusing in general and folks probably shouldn't be sending them to us. I think generally if we get them it is because someone made a mistake in their application. But we should still handle them.
The text was updated successfully, but these errors were encountered: