Enforcing mapped types

Quick question: I've created a very simple mapping of a field to be an
integer. A get of the _mapping shows the following:
$ curl -x '' -XGET 'http://localhost:9200/maptest/test/_mapping?
pretty=true'
{
"test" : {
"properties" : {
"name" : {
"type" : "string"
},
"int_test" : {
"store" : "yes",
"type" : "integer"
}
}
}
}

However, it doesn't seem that the mapping is being enforced. If I
create an object with a float or string value, it is accepted, and
future GETs have the same float or string. i.e.:

$ curl -x '' -XPOST 'http://localhost:9200/maptest/test' -d
'{ "name" : "whatever", "int_test" : 5.22 }'
{"ok":true,"_index":"maptest","_type":"test","_id":"oO3ShWAlQp693b4b4mW3UQ","_version":
1}

$curl -x '' -XGET 'http://localhost:9200/maptest/test/
oO3ShWAlQp693b4b4mW3UQ'
{"_index":"maptest","_type":"test","_id":"oO3ShWAlQp693b4b4mW3UQ","_version":
1,"exists":true, "_source" : { "name" : "whatever", "int_test" :
5.22 }}

$ curl -x '' -XGET 'http://localhost:9200/maptest/test/
oO3ShWAlQp693b4b4mW3UQ?fields=int_test'
{"_index":"maptest","_type":"test","_id":"oO3ShWAlQp693b4b4mW3UQ","_version":
1,"exists":true,"fields":{"int_test":5.22}}

What am I missing?

Thanks,

  • Ruben

Also, sorry I've posted this a few times.... was having trouble having
nabble recognize my subscription.

Hi Ruben

$curl -x '' -XGET 'http://localhost:9200/maptest/test/
oO3ShWAlQp693b4b4mW3UQ'
{"_index":"maptest","_type":"test","_id":"oO3ShWAlQp693b4b4mW3UQ","_version":
1,"exists":true, "_source" : { "name" : "whatever", "int_test" :
5.22 }}

When you get a doc, you get back exactly the same JSON that you put in.
That's not the same as the value that is being indexed.

clint

Right, I read in the documentation that the _source is simply the
original JSON, that's why we thought to try getting the individual
fields (i.e. fields=int_test), but even that returns the 5.22, so I'm
guessing that just pulls it from there, too.

I tried searching, and that returned the 5.22 as well:

$ curl -x '' -XGET 'http://localhost:9200/maptest/test/_search?
int_test=5'
{"took":2,"timed_out":false,"_shards":{"total":5,"successful":
5,"failed":0},"hits":{"total":1,"max_score":1.0,"hits":
[{"_index":"maptest","_type":"test","_id":"oO3ShWAlQp693b4b4mW3UQ","_score":
1.0, "_source" : { "name" : "whatever", "int_test" : 5.22 }}]}}

$ curl -x '' -XGET 'http://localhost:9200/maptest/test/_search?
int_test=5.22'
{"took":2,"timed_out":false,"_shards":{"total":5,"successful":
5,"failed":0},"hits":{"total":1,"max_score":1.0,"hits":
[{"_index":"maptest","_type":"test","_id":"oO3ShWAlQp693b4b4mW3UQ","_score":
1.0, "_source" : { "name" : "whatever", "int_test" : 5.22 }}]}}

I'm guessing that the second search returned the value because of the
_all field?

Is there a way to get the actual indexed value, or to have it reject
values that don't match the field type? Otherwise, I feel there's a
discrepancy between what I think a value is, and what it actually is.

  • Ruben

On Aug 3, 10:36 am, Clinton Gormley cl...@traveljury.com wrote:

Hi Ruben

$curl -x '' -XGET 'http://localhost:9200/maptest/test/
oO3ShWAlQp693b4b4mW3UQ'
{"_index":"maptest","_type":"test","_id":"oO3ShWAlQp693b4b4mW3UQ","_version ":
1,"exists":true, "_source" : { "name" : "whatever", "int_test" :
5.22 }}

When you get a doc, you get back exactly the same JSON that you put in.
That's not the same as the value that is being indexed.

clint

On Wed, 2011-08-03 at 08:12 -0700, rfq wrote:

Right, I read in the documentation that the _source is simply the
original JSON, that's why we thought to try getting the individual
fields (i.e. fields=int_test), but even that returns the 5.22, so I'm
guessing that just pulls it from there, too.

I tried searching, and that returned the 5.22 as well:

again, it just returns the _source

I'm guessing that the second search returned the value because of the
_all field?

Correct

Is there a way to get the actual indexed value, or to have it reject
values that don't match the field type? Otherwise, I feel there's a
discrepancy between what I think a value is, and what it actually is.

I don't think you can reject bad types.

To see what is actually happening, I've gisted a short example which
uses term facets to retrieve the actual values that are stored in a
field of type integer, float, and _all (which by default is a string
field).

clint

It won't reject a float value for an int field, it will simply convert it to
an int value.

On Wed, Aug 3, 2011 at 8:15 PM, Clinton Gormley clint@traveljury.comwrote:

On Wed, 2011-08-03 at 08:12 -0700, rfq wrote:

Right, I read in the documentation that the _source is simply the
original JSON, that's why we thought to try getting the individual
fields (i.e. fields=int_test), but even that returns the 5.22, so I'm
guessing that just pulls it from there, too.

I tried searching, and that returned the 5.22 as well:

again, it just returns the _source

I'm guessing that the second search returned the value because of the
_all field?

Correct

Is there a way to get the actual indexed value, or to have it reject
values that don't match the field type? Otherwise, I feel there's a
discrepancy between what I think a value is, and what it actually is.

I don't think you can reject bad types.

To see what is actually happening, I've gisted a short example which
uses term facets to retrieve the actual values that are stored in a
field of type integer, float, and _all (which by default is a string
field).

gist:e598ccfd3fa67830b689 · GitHub

clint

To see what is actually happening, I've gisted a short example which
uses term facets to retrieve the actual values that are stored in a
field of type integer, float, and _all (which by default is a string
field).

Apologies - i had some errors in my previous gist.

Corrected: gist:e598ccfd3fa67830b689 · GitHub

Cool, that makes sense, thanks.

On Aug 3, 1:57 pm, Clinton Gormley cl...@traveljury.com wrote:

To see what is actually happening, I've gisted a short example which
uses term facets to retrieve the actual values that are stored in a
field of type integer, float, and _all (which by default is a string
field).

Apologies - i had some errors in my previous gist.

Corrected:gist:e598ccfd3fa67830b689 · GitHub