Changing field type with create_mapping just hides the error

[clintongormley]

Easier to give an example than to explain:
- on a new cluster (ie no indices, no mappings)
- index a document with eg { foo: 123 } # sets type of foo to 'int'
- index a doc with { foo : "bar" } # throws an error
- create a mapping and set foo's type to 'string'
- index the doc with { foo: "bar"} # ok
- search for {term: { foo: 123}} # 1 hit
- search for {term: { foo: "bar"}} # no hits

So setting the mapping doesn't change the type of 'foo', it just hides the error message later on.

This seems inconsistent to me - it should either change the type of 'foo' going forward, or throw an error when you try to change the type with create_mapping.

Log file follows:

curl -XPUT http://127.0.0.2:9200/twitter/tweet/1 -d '{
   "foo" : 123
}
'
# {
#    "ok" : true,
#    "_index" : "twitter",
#    "_id" : "1",
#    "_type" : "tweet"
# }


curl -XPUT http://127.0.0.2:9200/twitter/tweet/2 -d '{
   "foo" : "bar"
}
'
# {
#    "debug" : {
#       "at" : {
#          "className" : "java.lang.Thread",
#          "methodName" : "run",
#          "fileName" : "Thread.java",
#          "lineNumber" : 619
#       },
#       "cause" : {
#          "at" : {
#             "className" : "java.lang.Thread",
#             "methodName" : "run",
#             "fileName" : "Thread.java",
#             "lineNumber" : 619
#          },
#          "message" : "Current token (VALUE_STRING) not numeric, c
# >         an not use numeric value accessors\n at [Source: {\n   
#       },
#       "message" : "Index[twitter] Shard[1] "
#    },
#    "error" : "Index[twitter] Shard[1] ; nested: Failed to parse; 
# >   nested: Current token (VALUE_STRING) not numeric, can not use
# }


curl -XPUT http://127.0.0.2:9200/_all/tweet/_mapping -d '{
   "properties" : {
      "foo" : {
         "type" : "string"
      }
   }
}
'
# {
#    "ok" : true
# }


curl -XPUT http://127.0.0.2:9200/twitter/tweet/2 -d '{
   "foo" : "bar"
}
'
# {
#    "ok" : true,
#    "_index" : "twitter",
#    "_id" : "2",
#    "_type" : "tweet"
# }


curl -XGET http://127.0.0.2:9200/twitter/tweet/_search -d '{
   "query" : {
      "term" : {
         "foo" : "123"
      }
   }
}
'
# {
#    "hits" : {
#       "hits" : [],
#       "total" : 0
#    },
#    "_shards" : {
#       "failed" : 0,
#       "successful" : 5,
#       "total" : 5
#    }
# }


curl -XGET http://127.0.0.2:9200/twitter/tweet/_search -d '{
   "query" : {
      "term" : {
         "foo" : "bar"
      }
   }
}
'
# {
#    "hits" : {
#       "hits" : [],
#       "total" : 0
#    },
#    "_shards" : {
#       "failed" : 5,
#       "successful" : 0,
#       "total" : 5
#    }
# }

[kimchy]

part of the mapper overhaul, this scenario should now work as expected. Basically, putting the new mapping will ignore conflicts so no exception on it

[clintongormley]

This works now. I note that searching on the wrong type (eg field set to type integer, and search for 'foo') now throws this error:

"SearchParseException[[twitter][0]: query[null],from[-1],size[-1]: Parse Failure [Failed to parse [[B@7e054643]]]; nested: NumberFormatException[For input string: "bar"]; "

May be worth tidying that up :)

[kimchy]

There is so much more work on getting proper exceptions out :)