BigDecimal columns are not mapped well about elasticsearch-grails-plugin

[noamt]

I'm not too sure about the issue, or if it has been fixed.
If you can create a test/project that reproduces the issue, or a pull request I'll be happy to take a look at it.
Otherwise, it'll take me a little more time to investigate.

[emfanitek]

Absolutely I'll do that.
On Feb 23, 2014 9:58 AM, "Noam Y. Tenne" [email protected] wrote:

I'm not too sure about the issue, or if it has been fixed.
If you can create a test/project that reproduces the issue, or a pull
request I'll be happy to take a look at it.
Otherwise, it'll take me a little more time to investigate.

Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-35827111
.

[emfanitek]

Test app here:

https://github.com/emfanitek/elasticsearch-gorm-plugin/blob/master/test-apps/es-bigdecimal.zip

Didn't know how to attach a binary file.

The app fails while starting up with the error:

[elasticsearch[Proteus][bulk][T#5]] ERROR index.IndexRequestQueue - Failed bulk item: MapperParsingException[object mapping for [author] tried to parse as object, but got EOF, has a concrete value been provided to it?]

[noamt]

Excellent, thanks much!

[emfanitek]

Replacing

static searchable =  true

with:

static searchable = {
    age converter:'long'
}

Allows mapping and indexing, but the converter is ignored due to this piece of code in ElasticSearchMappingFactory

            } else if (scpm.getConverter() != null) {
                // Use 'string' type for properties with custom converter.
                // Arrays are automatically resolved by ElasticSearch, so no worries.
                propType = 'string'

Why can't we use this instead?

            } else if (scpm.getConverter() != null) {
                // Arrays are automatically resolved by ElasticSearch, so no worries.
                String requestedConverter = scpm.getConverter()
                propType = (requestedConverter in SUPPORTED_FORMAT) ? requestedConverter : 'string'

[noamt]

BTW, isn't the 'string' converter preferable over 'long' for BigDecimal?
Doesn't conversion to long lose precision?

[emfanitek]

Well, that depends on what you wish to do with it. If you wish to use elastic search's ability to claculate totals and means, you need a numeric value. So string is no good in that case. Bigdecimal is multi purpose, can contain decimals or not, so we need to leave it to the application to map it to whatever primitive ES type necessary: string, double, or long.

[noamt]

I've deployed a new snapshot including a fix for the mapping, care to try it out before I release?
You can find it here

[emfanitek]

Great! I will, as soon as I have a moment!

On Wed, Mar 5, 2014 at 9:32 AM, Noam Y. Tenne [email protected]:

I've deployed a new snapshot including a fix for the mapping, care to try
it out?
You can find it herehttp://noams.artifactoryonline.com/noams/grails-elasticsearch-plugin-snapshots/org/grails/plugins/elasticsearch-gorm/0.0.2.x-SNAPSHOT/

Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-36720024
.

[noamt]

Will be included in the next release