-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Allow metadata fields in the _source #61590
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
Changes from 10 commits
8a65d1c
d83b677
76f3dc3
4934129
a168a1b
2effa2f
1f5aa63
78faca3
1346865
39d19fe
f0bb957
a734ea8
b8b3a9d
1560e73
0c962c4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -153,10 +153,35 @@ public final XContentBuilder toXContent(XContentBuilder builder, Params params) | |||
return builder.endObject(); | ||||
} | ||||
|
||||
/* | ||||
* By default metadata fields cannot be set through the document source and parse() method | ||||
* throws an exception. To enable a metadata field to parse the document source, this | ||||
* method must be overridden and doParse() should be called. | ||||
*/ | ||||
@Override | ||||
public void parse(ParseContext context) throws IOException { | ||||
throw new MapperParsingException("Field [" + name() + "] is a metadata field and cannot be added inside" | ||||
+ " a document. Use the index API request parameters."); | ||||
} | ||||
|
||||
/** | ||||
* Do the actual parse of the field by calling {@link FieldMapper#parse(ParseContext)} | ||||
*/ | ||||
protected void doParse(ParseContext context) throws IOException { | ||||
super.parse(context); | ||||
} | ||||
|
||||
@Override | ||||
protected void parseCreateField(ParseContext context) throws IOException { | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Instead of overriding
Then we could do the following:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for pointing this out. I had a hard time thinking a simple and clean way to refactor this part. Initially, I tried the approach you suggested, but (See elasticsearch/server/src/main/java/org/elasticsearch/index/mapper/FieldMapper.java Line 249 in 9a127ad
This means that the
will be encapsulated in the following exception:
On the other hand, methods Since all There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To me that approach you tried/ I suggested is the cleanest way to go. My reasoning...
This seems like an okay compromise to me, all the exception information is there so the user can determine the cause. It's a little confusing that we wrap the message, but this should be a rare situation.
I think that exception handling code is only really helpful when dealing with incorrect user-supplied values. Since |
||||
// do nothing | ||||
} | ||||
|
||||
/** | ||||
* Called before {@link FieldMapper#parse(ParseContext)} on the {@link RootObjectMapper}. | ||||
*/ | ||||
public abstract void preParse(ParseContext context) throws IOException; | ||||
public void preParse(ParseContext context) throws IOException { | ||||
// do nothing | ||||
} | ||||
|
||||
/** | ||||
* Called after {@link FieldMapper#parse(ParseContext)} on the {@link RootObjectMapper}. | ||||
|
@@ -169,5 +194,4 @@ public void postParse(ParseContext context) throws IOException { | |||
public ValueFetcher valueFetcher(MapperService mapperService, SearchLookup lookup, String format) { | ||||
throw new UnsupportedOperationException("Cannot fetch values for internal field [" + name() + "]."); | ||||
} | ||||
|
||||
} |
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 just noticed we're doing a linear scan through all the metadata mappers. Maybe we should make sure to store them as a map from name -> mapper to avoid this overhead?
Uh oh!
There was an error while loading. Please reload this page.
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.
You are right. I had this point in mind for improvement. I just saw that linear scan happens at:
elasticsearch/server/src/main/java/org/elasticsearch/index/mapper/DocumentParser.java
Line 101 in b8b3a9d
I understand that pre/postParse()
internalParseDocument()
is called once per document, while the linear scan ingetMapper()
is executed once per metadata field.I will fix this asap!
Uh oh!
There was an error while loading. Please reload this page.
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.
Fixed this last bit. Can you please have one last look?
Thank you for your patience and excellent guidance.
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.
The change makes sense to me.
It feels redundant that we store an array of metadata mappers, a map from class -> mapper, and a map from name -> mapper. This could be simplified, but we don't necessarily need to do it in this PR.