Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Mapping not working #11
Following the examples in your docs, create-mapping does not seem to work, eg:
I tried creating the index first, but same thing.
Also, the JSON format for specifying the mapping type to use when indexing a document is ambiguous, eg:
Does that mean that the document has mapping type 'tweet', or that there is no mapping type specified, and it has a single top level key called 'tweet'.
And one thing i'm not sure about? Is a mapping the same thing as a type? So you would never have type 'foo' and mapping 'bar'?
There is a bug in the docs (which I just fixed), the url for it should be http://localhost:9200/twitter/tweet/_mapping. Here is the example:
You first need to create the index explicitly to add mappings. I will add another issue so the index will be created automatically in this case.
Not sure that I understand why its ambiguous? The indexable content can have the type as the first level JSON field, but its optional (since the type already exists in the url and I can derive it from that).
Mappings are basically meta data on how to map the indexable JSON content of a type into the search engine. You can have more than one type, and each type can optionally have mapping defined for it.
OK, so there is one mapping per index+type. Gotcha.
The reason that including the mapping name in the JSON is ambiguous is because of object type mappings. Without a predefined mapping, you don't know if the top level 'tweet' key is a mapping name, or the first key in the object being stored.
So either you have to always specify the mapping, so the second case would look like:
or never specify the mapping in the JSON, and just use the 'type' from the URL as the mapping name (which would be my preference)
I think that having it as either-or is a mistake, yes.
Not sure which is the better interface though. My feeling (having just written a Perl interface to ElasticSearch) is that you have to generate the URL and the JSON anyway, and it looks more consistent to me to specify the type in the URL, and the data in the JSON.
But as I say, it makes little difference to me which version you settle on.
Let me think about it a bit more. The only case where it will break is if the case you noted, (JSON object with the type name, and another JSON object with the same type name) and I am not sure if people will ever generate a JSON like that. I like the ability to try and support both...