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

Check if root mapping is actually valid #6093

Closed
wants to merge 7 commits into from
Closed

Conversation

brwe
Copy link
Contributor

@brwe brwe commented May 8, 2014

When a mapping is declared and the type is known from the uri
then the type can be skipped in the body (see #4483). However,
there was no check if the given keys actually make a valid mapping.

closes #5864

private void checkRootKeysValid(Map<String, Object> root) {
for (String key : root.keySet()) {
if (!rootTypeParsers.containsKey(key) && !key.equals("properties")) {
throw new MapperParsingException("Got unrecognized key "+ key + " in root of mapping for type ");
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe enclose key with brackets to make clearer where it starts and where it ends?

throw new MapperParsingException("Got unrecognized key ["+ key + "] in root of mapping for type");

@jpountz jpountz removed the review label May 9, 2014
@brwe
Copy link
Contributor Author

brwe commented May 9, 2014

I added some commits to implement the comments. I am unsure about the RootObjectMapper properties ("dynamic_templates", ...). I added two commits: One just checks for all the field names that I found in the RootObjectMapper code ("check rootObjectMapper keys also") and another that converts the Strings that are checked in there to ParseFields ("make RootObjectMapper keys ParseFields") but I am unsure if this makes the code much better.

@brwe
Copy link
Contributor Author

brwe commented May 9, 2014

There are still options missing, like "analyzer", "index_analyzer",...
I'll update the pull request.

When a mapping is declared and the type is known from the uri
then the type can be skipped in the body (see elastic#4483). However,
there was no check if the given keys actually make a valid mapping.

closes elastic#5864
@brwe
Copy link
Contributor Author

brwe commented May 10, 2014

I pushed a new version, the old one can still be found at: https://github.com/brwe/elasticsearch/tree/issue-5864-v1

Instead of collecting all keys that can be in a root object mapping I split the root object and object parsing into properties that can be in the root object, those that can't and those that can be in both. In the root object parsing, I remove each found key from the mapping and then check if the mapping is empty after parsing. This has the nice side effect that now also mappings of the form { "TYPME_NAME": { are parsed and therefore there is a pretty high test coverage I think. This also revealed that I missed many of the root object properties in my first draft. Thanks for the tip, @jpountz!

@brwe brwe added the review label May 10, 2014
docBuilder.put(typeParser.parse(fieldName, (Map<String, Object>) fieldNode, parserContext));
}
}
}

ImmutableMap<String, Object> attributes = ImmutableMap.of();
if (mapping.containsKey("_meta")) {
attributes = ImmutableMap.copyOf((Map<String, Object>) mapping.get("_meta"));
Copy link
Contributor

Choose a reason for hiding this comment

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

you can replace the call to get with a call to remove to not need to remove the _meta key on the next line

@jpountz
Copy link
Contributor

jpountz commented May 12, 2014

Apart from minor style issues this looks good to me.

@brwe
Copy link
Contributor Author

brwe commented May 12, 2014

thanks for the review, I added some commits

@jpountz
Copy link
Contributor

jpountz commented May 12, 2014

LGTM!

brwe added a commit that referenced this pull request May 12, 2014
When a mapping is declared and the type is known from the uri
then the type can be skipped in the body (see #4483). However,
there was no check if the given keys actually make a valid mapping.

closes #5864
closes #6093
@brwe brwe closed this in 4b2e4be May 12, 2014
brwe added a commit to brwe/elasticsearch that referenced this pull request May 30, 2014
include_in_all can also be set on type level (root object).
This fixes a regression introduced  in elastic#6093

closes elastic#6304
brwe added a commit that referenced this pull request Jun 2, 2014
include_in_all can also be set on type level (root object).
This fixes a regression introduced  in #6093

closes #6304
brwe added a commit that referenced this pull request Jun 2, 2014
include_in_all can also be set on type level (root object).
This fixes a regression introduced  in #6093

closes #6304
brwe added a commit that referenced this pull request Jun 2, 2014
include_in_all can also be set on type level (root object).
This fixes a regression introduced  in #6093

closes #6304
@s1monw s1monw removed the review label Jun 18, 2014
@clintongormley clintongormley added >enhancement :Search Foundations/Mapping Index mappings, including merging and defining field types labels Jun 8, 2015
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
include_in_all can also be set on type level (root object).
This fixes a regression introduced  in elastic#6093

closes elastic#6304
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search Foundations/Mapping Index mappings, including merging and defining field types v1.2.0 v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error handling on invalid mapping data
4 participants