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

Elasticsearch should raise a mapper exception when reserved "mapping fields" are used inside "properties" #10456

Closed
konradkonrad opened this issue Apr 7, 2015 · 3 comments
Assignees
Labels
>bug help wanted adoptme :Search Foundations/Mapping Index mappings, including merging and defining field types

Comments

@konradkonrad
Copy link
Contributor

Unfortunately it is possible to use "top-level"/meta mapping properties, such as _source, _all, ... inside the "properties": {} portion of a mapping, without complaints. This allows for user errors that are easily missed.

Using the following mapping

{
  "t1": {
    "_source": {"enabled": false}, 
    "properties": {
      "_all": {"enabled": false},
      "field1": {"type": "string"},
      "field2": {"type": "long"},
      "_underscore1": {"type": "string"},
      "_underscore2": {"enabled": true}
    }
  }
}

will lead to:

{
  "mytest" : {
    "mappings" : {
      "t1" : {
        "_source" : {
          "enabled" : false
        },
        "properties" : {
          "_underscore1" : {
            "type" : "string"
          },
          "_underscore2" : {
            "type" : "object"
          },
          "field1" : {
            "type" : "string"
          },
          "field2" : {
            "type" : "long"
          }
        }
      }
    }
  }
}

Note, how the _all-"Field-Mapping" is just silently ignored.

Please see https://gist.github.com/konradkonrad/16220520eb9bacc1f6e6 for a complete reproduction.

@clintongormley
Copy link

Relates to #9059

@konradkonrad
Copy link
Contributor Author

@clintongormley thx for labelling this!

While I totally agree on the relation to #9059, I believe this one should/could be addressed ahead of time, since atm there exists a set of should-be-reserved words: Mapping » Fields*)

As the _all example seems to show, there is also some validation already in place. I cannot tell how many users use ambigous field names such as _timestamp, and I understand the BC concerns of #9059 -- however from my POV I'd rather have users become aware of their misconfigured mappings, then serve the BC needs of mappings using questionable ambigous names.

*) SN: btw. pretty unfortunate naming in the docs imho, what about one of these?

  • Mapping » DocType Configuration
  • Mapping » DocType Settings
  • Mapping » Mapping Configuration
  • Mapping » Top-Level Fields

@jpountz
Copy link
Contributor

jpountz commented Dec 23, 2015

Fixed via #15243

@jpountz jpountz closed this as completed Dec 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug help wanted adoptme :Search Foundations/Mapping Index mappings, including merging and defining field types
Projects
None yet
Development

No branches or pull requests

3 participants