-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Make flattened synthetic source concatenate object keys on scalar/object mismatch #129600
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
base: main
Are you sure you want to change the base?
Make flattened synthetic source concatenate object keys on scalar/object mismatch #129600
Conversation
.../main/java/org/elasticsearch/index/mapper/flattened/FlattenedFieldSyntheticWriterHelper.java
Outdated
Show resolved
Hide resolved
.../main/java/org/elasticsearch/index/mapper/flattened/FlattenedFieldSyntheticWriterHelper.java
Outdated
Show resolved
Hide resolved
next = nextValue == null ? KeyValue.EMPTY : new KeyValue(nextValue); | ||
|
||
var startPrefix = curr.prefix.diff(openObjects); | ||
if (startPrefix.prefix.isEmpty() == false && startPrefix.prefix.getFirst().equals(lastScalarSingleLeaf)) { |
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.
What if the conflict doesn't happen on the first part of the prefix, e.g.
field {
path {
to: 10
to {
foo: bar
}
}
}
Would this be caught here?
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.
Yep, so this will become:
field {
path {
to: 10
to.foo: bar
}
}
When it get to the first key/value field.path.to|10
it will take the else block and traverse down into the object, adding field
and path
to the openObject
context. When it reaches the key value field.path.to.foo|bar
that object will still be open, and seeing that lastScalarSingleLeaf
has a value of to
, and that to
is the first token in the startPrexix (to.foo
), it will make a concatenated path.
(Updated a test to this situation to verify it)
.../main/java/org/elasticsearch/index/mapper/flattened/FlattenedFieldSyntheticWriterHelper.java
Outdated
Show resolved
Hide resolved
@@ -103,7 +103,7 @@ public void testSingleObject() throws IOException { | |||
|
|||
// THEN | |||
assertEquals( | |||
"{\"a\":\"value_a\",\"a\":{\"b\":\"value_b\",\"b\":{\"c\":\"value_c\"},\"d\":\"value_d\"}}", | |||
"{\"a\":\"value_a\",\"a.b\":\"value_b\",\"a.b.c\":\"value_c\",\"a.d\":\"value_d\"}", |
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.
Interestingly, there was a test which had a scalar/object mismatch. But it produced duplicate keys. When the xcontent was converted to jsont these duplicate keys originally threw an error, but now just drop the duplicates. (Something must have changed in xcontent stuff since the issue was opened to cause this change from an error to deduplication)
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
Hi @parkertimmins, I've created a changelog YAML for you. |
There is an issue where for Flattened fields with synthetic source, if there is a key with a scalar value, and a duplicate key with an object value, one of the values will be left out of the produced synthetic source.
This fixes the issue by replacing the problematic object with paths to each of its keys. These paths consist of the concatenation of all keys going down to a given scalar, joined by
.
. For example, they are of the formfoo.bar.baz
. This applies recursively, so that every value within the object, no matter how nested, will be accessible through a full specified path.For example if the following flattened field values is indexed:
The following synthetic source will be produced:
Fixes #122936