-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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 generic fallback implementation for synthetic source #108222
Conversation
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
Hi @lkts, I've created a changelog YAML for you. |
*/ | ||
@Override | ||
public SourceLoader.SyntheticFieldLoader syntheticFieldLoader() { | ||
return SourceLoader.SyntheticFieldLoader.NOTHING; |
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.
This is nothing because ObjectMapper
already nicely adds all ignored source fields to the source.
@@ -219,7 +229,138 @@ protected Object generateRandomInputValue(MappedFieldType ft) { | |||
|
|||
@Override | |||
protected SyntheticSourceSupport syntheticSourceSupport(boolean ignoreMalformed) { |
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.
I started adding tests here because it looks like the most complex type. I am not sure how should we proceed - if this PR contains tests for all fields that now have support, it will be quite big.
|
||
@Override | ||
protected BlockReaderSupport getSupportedReaders(MapperService mapper, String loaderFieldName) { | ||
// TODO are we okay that we don't support synthetic source 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.
My understanding of block loader stuff is still quite weak, i am not sure what's expected here.
protected boolean supportsCopyTo() { | ||
// TODO this is so that `testSyntheticSourceInvalid` does not complain | ||
// in theory geo_shape could support copy_to | ||
// should we fail to construct synthetic source in `FieldMapper` if there is copy_to ? |
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.
Another question here.
Here is another interesting observation. Currently |
I am thinking we should opt-in into this one field at a time by setting |
cb1626e
to
d14b959
Compare
* If a mapper opts in to use fallback synthetic source implementation. | ||
* @return true or false | ||
*/ | ||
protected boolean fallbackSyntheticSourceOptIn() { |
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.
If implementations overwrite this method, why would these implementations implement synthetic source natively? It is the same as supportsSyntheticSourceNatively()
returning false?
Maybe we can just have supportsSyntheticSourceNatively()
?
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.
This is a temporary flag just to be able to introduce support on a per-field basis instead of one big PR. We will remove this when we enable synthetic source support for the last field.
server/src/main/java/org/elasticsearch/common/xcontent/XContentHelper.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/index/mapper/DocumentParser.java
Outdated
Show resolved
Hide resolved
@elasticmachine update branch |
server/src/main/java/org/elasticsearch/common/xcontent/XContentHelper.java
Outdated
Show resolved
Hide resolved
index: test | ||
id: "2" | ||
|
||
- match: { _source.a_field: null } |
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.
Add an array test too?
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.
Great catch! I for some reason assumed that this field does not support arrays.
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.
I'll actually do that in a small follow-up.
@@ -54,6 +54,11 @@ public class IgnoredSourceFieldMapper extends MetadataFieldMapper { | |||
* - the value, encoded as a byte array | |||
*/ | |||
public record NameValue(String name, int parentOffset, BytesRef value) { | |||
public static NameValue fromContext(DocumentParserContext context, String name, BytesRef value) { |
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.
This only applies to fields, not objects.. Maybe rename to fromContextField
or something like this, and add a short comment describing what it does.
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.
I am not sure i understand why would it not work for objects. I'll rename in a follow-up.
Looks good. I'm not sure if array fields are covered too, maybe add a few tests for it. It's fine to deal with them in a follow-up if needed, though. |
@elasticmachine update branch |
This PR extends #108222 adding support for arrays.
This PR uses infrastructure from #107567 to implement a fallback implementation of synthetic source for field mappers that don't support it natively. In that case we will store source of such field as is in a separate stored field.
Pending work:
copy_to
handling.copy_to
is currently not allowed on fields when synthetic source is used, should this be applied uniformly?Note that this PR does not cover
nested
as it is not aFieldMapper
however it can be done using similar approach separately.