Elasticsearch version: 2.3.3
JVM version: 1.8.0_91
OS version: Ubuntu 14.04
Description of the problem including expected versus actual behavior:
At first, I'm not sure if I misread the docs and this is not expected behavior, in which case, please look at this as an issue instead. Arrays of IPs don't seem to be able to be made. Whenever one pre-defines the mapping, and tries to create one, a type mismatch happens.
Steps to reproduce:
I'm following the ones someone suggested I follow on the discussion board. Credit to msimos.
curl -XPUT 'http://localhost:9200/com' -d '{
"mappings": {
"type": {
"properties": {
"ips": {
"type": "ip"
}
}
}
}
}'
curl -XPOST 'http://localhost:9200/com/anytype/1' -d '{
"ips": ["123.123.123.123", "10.0.0.1"]
}'
{
"error": {
"root_cause": [{
"type": "mapper_parsing_exception",
"reason": "failed to parse"
}],
"type": "mapper_parsing_exception",
"reason": "failed to parse",
"caused_by": {
"type": "illegal_state_exception",
"reason": "Mixing up field types: class org.elasticsearch.index.mapper.core.LongFieldMapper$LongFieldType != class org.elasticsearch.index.mapper.ip.IpFieldMapper$IpFieldType on field ips"
}
},
"status": 400
}
Note, this is fixed in master
@clintongormley Thanks for the reply! How can I upgrade to master? I understand its not an official release but I was wondering what would be the cleanest way of upgrading to that version. I could really use not having that type mismatch. Thanks again!
OK I found the bug, this is unrelated to the use of arrays and is indeed fixed in master. What is happening here is that ips is already defined in type but not in anytype. For that cases, we have some logic that tries to borrow the mapping definitions from existing types, but it only works for types that are supported in templates currently (numbers, date and string), so it fails with ip addresses.
I will open a PR soon, but you can work around the problem by defining your ip field in the _default_ mapping so that it will be used by all types.
Actually this was fixed by #17882 so I just backported it.
This will be addressed in the upcoming 2.4.0 release.
@jpountz Thanks for the update! How do I go about defining the ip field in the _default_ mapping?
Is it just a PUT request with:?
{
"_default_": {
"_all": {
"type": "ip"
}
}
}
That would be something like this:
curl -XPUT 'http://localhost:9200/com' -d '{
"mappings": {
"_default_": {
"properties": {
"ips": {
"type": "ip"
}
}
}
}
}'
thank you very much!
Most helpful comment
OK I found the bug, this is unrelated to the use of arrays and is indeed fixed in master. What is happening here is that
ipsis already defined intypebut not inanytype. For that cases, we have some logic that tries to borrow the mapping definitions from existing types, but it only works for types that are supported in templates currently (numbers, date and string), so it fails with ip addresses.I will open a PR soon, but you can work around the problem by defining your ip field in the
_default_mapping so that it will be used by all types.