Wrong mapping using a nested object with same name as its type

[javanna]

When I index a document in elasticsearch 0.90.0 and I have nested objects, one of which has the same name as its type, the automatically submitted mapping is wrong and basic queries don't work anymore.

Here is the curl recreation: https://gist.github.com/javanna/5531326 .

Indexing an object like this under the "type" type, with empty mapping:

{
  "type": {
    "id" : "test id",
    "title" : "test title"  
  },
  "type2" : {
    "id" : "test"
  }
}

The updated mapping becomes the following:

{
  "type" : {
    "properties" : {
      "id" : {
        "type" : "string"
      },
      "title" : {
        "type" : "string"
      }
    }
  }
}

I would expect to see a type2 nested object but I can't find it, and any query on the nested type2 object doesn't return any result.
The problem seems to be caused by the name of the type used to index the document, which is the same as the name of one the nested objects. If I change that I don't see any problem.

[kimchy]

The problem is that the top level element in the doc is called type, which matches the mapping name type, so when providing a doc with a top level object name as the mapping name, it will just treat that object. This is to support the following case and not have "double" type1 mapping:

curl -XPUT localhost:9200/index/type1/1 - d '{
   "type1" : {
        ....
   }
}

So, in your case, make sure the mapping name is not the same as the top level element if you don't provide your json docs wrapped with the type name.

[clintongormley]

Does anybody use that double type (ie url + json)? This seems like an alternative which could be removed fairly painlessly.

[javanna]

Cool! I didn't know this was supposed to happen. I already changed the type name.

On the other hand I'm not quite sure if anybody is actually using this feature. I would expect elasticsearch not to care too much about the content of my documents and give me a mapping like this:

{
  "type1" : {
    "properties" : {
        "type1" : {
            "type" : "object",
            "properties" : {
                ......
            }
        },
        "type2" : {
            "type" : "object",
            "properties" : {
                ......
            }
        }
    }
  }
}

My two cents: I would prefer to have the type1 subobject even if it's the only existing subobject in my documents rather than have my type2 subobject ignored.

[kimchy]

It all goes back to the early history of elasticsearch, a lot of users were confused about the double mapping when they were wrapping the document they were indexing with the type name (some auto domain_objects -> json tools do that). I agree that we could fail the indexing request if there is something we don't expect.

[javanna]

I see! Well, if you want to be more backwards compatible you can probably check if the top level object with the type name is the only one available in the document (thus probably not needed) in order to avoid ignoring other nested objects, but I don't like this option that much myself.

[clintongormley]

Yeah, I'd prefer there to be just one definitive way to do it, so that we don't have to guess.

[clintongormley]

Would be good to resolve this issue in 1.0, even though it requires breaking bwc.

The body of an indexing request should be just that: the body, not possibly the body wrapped in the type. Type should be specified only in the URL.

[timeu]

I think this issue is also related to has_parent and has_child queries/filters:

https://groups.google.com/d/msg/elasticsearch/8yTX17uoFiU/xGjYd4tfEzAJ

[clintongormley]

Closed this issue in favour of:

• Don't repeat type name in update mapping #4483
• Don't accept type wrapper in index request #4484
• Field resolution should be unambiguous #4081