# BigDecimal support **URL:** \ **Category:** Elasticsearch\ **Created:** [February 26, 2014, 5:05pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040 "2014-02-26T17:05:27Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [February 26, 2014, 5:05pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/1 "2014-02-26T17:05:27Z")
In financial services space, we almost never use float/double in our domain - we always use BigDecimal. In elastic, I would like to be able to index/store BigDecimal in a lossless manner (ie what I get back from \_source has the same precision, etc as what I put in). When I have had to preserve the json serialisation of BigDecimal, I have usually had custom serialiser/deserialisers that printed it out as a json number - but whose textual value was toPlainString(). When deserialising, creating the BigDecimal with the string value (e.g. '42.5400') maintained the precision that was originally serialised e.g. { verySmallNumber : 0.00000000012000, otherNumber : 42.5400 } Perhaps elastic could index bigdecimal as a double - but store it in the source in a lossless fashion. It would require a user setting, I guess, to treat all floating point numbers as BigDecimal. Thoughts? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [February 26, 2014, 5:28pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/2 "2014-02-26T17:28:29Z")
ES accepts BigDecimal input. You can specify scale and rounding mode to format the BigDecimal. [https://github.com/jprante/elasticsearch/commit/8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec](https://github.com/jprante/elasticsearch/commit/8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec) Internally, BigDecimal is automatically converted to a JSON string if the number does not fit into double format. Because numbers are useful in Lucene for range searches, they have an advantage. But I agree, another option could be to enforce string conversion in any case, for example storing currency values as strings for financial services, without arithmetic operations in the index. Maybe the toEngineeringString() was not a smart decision and toPlainString() works better. So I would welcome improvements, or should I suggest one in a pull request? Jörg On Wed, Feb 26, 2014 at 6:05 PM, mooky [nick.minutello@gmail.com](mailto:nick.minutello@gmail.com) wrote: > In financial services space, we almost never use float/double in our > domain - we always use BigDecimal. > > In elastic, I would like to be able to index/store BigDecimal in a > lossless manner (ie what I get back from \_source has the same precision, > etc as what I put in). > > When I have had to preserve the json serialisation of BigDecimal, I have > usually had custom serialiser/deserialisers that printed it out as a json > number - but whose textual value was toPlainString(). When deserialising, > creating the BigDecimal with the string value (e.g. '42.5400') maintained > the precision that was originally serialised > e.g. > > { > verySmallNumber : 0.00000000012000, > otherNumber : 42.5400 > } > > Perhaps elastic could index bigdecimal as a double - but store it in the > source in a lossless fashion. > It would require a user setting, I guess, to treat all floating point > numbers as BigDecimal. > > Thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com) > . > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGBKpPHFN%3DoFFka%3Dk%3Dtk%3DOLmSqB9kbY0RSOC0nM4C5Lww%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGBKpPHFN%3DoFFka%3Dk%3Dtk%3DOLmSqB9kbY0RSOC0nM4C5Lww%40mail.gmail.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [February 28, 2014, 12:09pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/3 "2014-02-28T12:09:00Z")
XContentBuilder has support for BigDecimal, but: 1. If you pass the source as a Map when indexing, the BigDecimal handling doesn't get invoked ([IndexRequestBuilder.setSource(Map\ source) does not handle BigDecimal · Issue #5260 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/5260)). 2. The existing handling should delegate through to Jackson's handling of BigDecimal (which can be configured to serialise BigDecimal in a lossless fashion - I dont think that feature existed when I had to worry about it last) Looking at the code now, I think its actually an easy change - I will see if I can create a pull request. -Nick On Wednesday, 26 February 2014 17:28:29 UTC, Jörg Prante wrote: > ES accepts BigDecimal input. You can specify scale and rounding mode to > format the BigDecimal. > > [https://github.com/jprante/elasticsearch/commit/8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec](https://github.com/jprante/elasticsearch/commit/8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec) > > Internally, BigDecimal is automatically converted to a JSON string if the > number does not fit into double format. Because numbers are useful in > Lucene for range searches, they have an advantage. > > But I agree, another option could be to enforce string conversion in any > case, for example storing currency values as strings for financial > services, without arithmetic operations in the index. > > Maybe the toEngineeringString() was not a smart decision and > toPlainString() works better. > > So I would welcome improvements, or should I suggest one in a pull request? > > Jörg > > On Wed, Feb 26, 2014 at 6:05 PM, mooky \<[nick.mi...@gmail.com](mailto:nick.mi...@gmail.com) \ > > > wrote: > > > In financial services space, we almost never use float/double in our > > domain - we always use BigDecimal. > > > > In elastic, I would like to be able to index/store BigDecimal in a > > lossless manner (ie what I get back from \_source has the same precision, > > etc as what I put in). > > > > When I have had to preserve the json serialisation of BigDecimal, I have > > usually had custom serialiser/deserialisers that printed it out as a json > > number - but whose textual value was toPlainString(). When deserialising, > > creating the BigDecimal with the string value (e.g. '42.5400') maintained > > the precision that was originally serialised > > e.g. > > > > { > > verySmallNumber : 0.00000000012000, > > otherNumber : 42.5400 > > } > > > > Perhaps elastic could index bigdecimal as a double - but store it in the > > source in a lossless fashion. > > It would require a user setting, I guess, to treat all floating point > > numbers as BigDecimal. > > > > Thoughts? > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com) > > . > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/418b171f-ea20-4416-8324-d7b3b5d113f7%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/418b171f-ea20-4416-8324-d7b3b5d113f7%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [March 5, 2014, 1:24pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/4 "2014-03-05T13:24:38Z")
I am ready to create a pull request - its actually quite a simple change. However, I cant find \*any \*tests for the existing BigDecimal support ... does that sound right? -Nick On Friday, 28 February 2014 12:09:00 UTC, mooky wrote: > XContentBuilder has support for BigDecimal, but: > > 1. If you pass the source as a Map when indexing, the BigDecimal > handling doesn't get invoked ( > [IndexRequestBuilder.setSource(Map\ source) does not handle BigDecimal · Issue #5260 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/5260)). > 2. The existing handling should delegate through to Jackson's handling > of BigDecimal (which can be configured to serialise BigDecimal in a > lossless fashion - I dont think that feature existed when I had to worry > about it last) > > Looking at the code now, I think its actually an easy change - I will see > if I can create a pull request. > > -Nick > > On Wednesday, 26 February 2014 17:28:29 UTC, Jörg Prante wrote: > > > ES accepts BigDecimal input. You can specify scale and rounding mode to > > format the BigDecimal. > > > > [https://github.com/jprante/elasticsearch/commit/8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec](https://github.com/jprante/elasticsearch/commit/8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec) > > > > Internally, BigDecimal is automatically converted to a JSON string if the > > number does not fit into double format. Because numbers are useful in > > Lucene for range searches, they have an advantage. > > > > But I agree, another option could be to enforce string conversion in any > > case, for example storing currency values as strings for financial > > services, without arithmetic operations in the index. > > > > Maybe the toEngineeringString() was not a smart decision and > > toPlainString() works better. > > > > So I would welcome improvements, or should I suggest one in a pull > > request? > > > > Jörg > > > > On Wed, Feb 26, 2014 at 6:05 PM, mooky [nick.mi...@gmail.com](mailto:nick.mi...@gmail.com) wrote: > > > > > In financial services space, we almost never use float/double in our > > > domain - we always use BigDecimal. > > > > > > In elastic, I would like to be able to index/store BigDecimal in a > > > lossless manner (ie what I get back from \_source has the same precision, > > > etc as what I put in). > > > > > > When I have had to preserve the json serialisation of BigDecimal, I have > > > usually had custom serialiser/deserialisers that printed it out as a json > > > number - but whose textual value was toPlainString(). When deserialising, > > > creating the BigDecimal with the string value (e.g. '42.5400') maintained > > > the precision that was originally serialised > > > e.g. > > > > > > { > > > verySmallNumber : 0.00000000012000, > > > otherNumber : 42.5400 > > > } > > > > > > Perhaps elastic could index bigdecimal as a double - but store it in the > > > source in a lossless fashion. > > > It would require a user setting, I guess, to treat all floating point > > > numbers as BigDecimal. > > > > > > Thoughts? > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac%40googlegroups.com) > > > . > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [March 5, 2014, 1:48pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/5 "2014-03-05T13:48:58Z")
Yes, there are no tests yet. Jörg On Wed, Mar 5, 2014 at 2:24 PM, mooky [nick.minutello@gmail.com](mailto:nick.minutello@gmail.com) wrote: > I am ready to create a pull request - its actually quite a simple change. > However, I cant find \*any \*tests for the existing BigDecimal support ... > does that sound right? > > -Nick > > On Friday, 28 February 2014 12:09:00 UTC, mooky wrote: > > > XContentBuilder has support for BigDecimal, but: > > > > 1. If you pass the source as a Map when indexing, the BigDecimal > > handling doesn't get invoked ([https://github.com/](https://github.com/) > > elasticsearch/elasticsearch/issues/5260[https://github.com/elasticsearch/elasticsearch/issues/5260](https://github.com/elasticsearch/elasticsearch/issues/5260) > > ). > > 2. The existing handling should delegate through to Jackson's > > handling of BigDecimal (which can be configured to serialise BigDecimal in > > a lossless fashion - I dont think that feature existed when I had to worry > > about it last) > > > > Looking at the code now, I think its actually an easy change - I will see > > if I can create a pull request. > > > > -Nick > > > > On Wednesday, 26 February 2014 17:28:29 UTC, Jörg Prante wrote: > > > > > ES accepts BigDecimal input. You can specify scale and rounding mode to > > > format the BigDecimal. > > > > > > [https://github.com/jprante/elasticsearch/commit/](https://github.com/jprante/elasticsearch/commit/) > > > 8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec > > > > > > Internally, BigDecimal is automatically converted to a JSON string if > > > the number does not fit into double format. Because numbers are useful in > > > Lucene for range searches, they have an advantage. > > > > > > But I agree, another option could be to enforce string conversion in any > > > case, for example storing currency values as strings for financial > > > services, without arithmetic operations in the index. > > > > > > Maybe the toEngineeringString() was not a smart decision and > > > toPlainString() works better. > > > > > > So I would welcome improvements, or should I suggest one in a pull > > > request? > > > > > > Jörg > > > > > > On Wed, Feb 26, 2014 at 6:05 PM, mooky [nick.mi...@gmail.com](mailto:nick.mi...@gmail.com) wrote: > > > > > > > In financial services space, we almost never use float/double in our > > > > domain - we always use BigDecimal. > > > > > > > > In elastic, I would like to be able to index/store BigDecimal in a > > > > lossless manner (ie what I get back from \_source has the same precision, > > > > etc as what I put in). > > > > > > > > When I have had to preserve the json serialisation of BigDecimal, I > > > > have usually had custom serialiser/deserialisers that printed it out as a > > > > json number - but whose textual value was toPlainString(). When > > > > deserialising, creating the BigDecimal with the string value (e.g. > > > > '42.5400') maintained the precision that was originally serialised > > > > e.g. > > > > > > > > { > > > > verySmallNumber : 0.00000000012000, > > > > otherNumber : 42.5400 > > > > } > > > > > > > > Perhaps elastic could index bigdecimal as a double - but store it in > > > > the source in a lossless fashion. > > > > It would require a user setting, I guess, to treat all floating point > > > > numbers as BigDecimal. > > > > > > > > Thoughts? > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac% > > > > [40googlegroups.com](http://40googlegroups.com). > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGYL7-\_ocoZNq%2Bv71z-o6Jisi3J\_8mVmsqU1UJuzWjPog%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGYL7-_ocoZNq%2Bv71z-o6Jisi3J_8mVmsqU1UJuzWjPog%40mail.gmail.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [March 10, 2014, 5:28pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/6 "2014-03-10T17:28:24Z")
Righto - I will try add some. -Nick On Wednesday, 5 March 2014 13:48:58 UTC, Jörg Prante wrote: > Yes, there are no tests yet. > > Jörg > > On Wed, Mar 5, 2014 at 2:24 PM, mooky \<[nick.mi...@gmail.com](mailto:nick.mi...@gmail.com) \\>wrote: > > > I am ready to create a pull request - its actually quite a simple change. > > However, I cant find \*any \*tests for the existing BigDecimal support ... > > does that sound right? > > > > -Nick > > > > On Friday, 28 February 2014 12:09:00 UTC, mooky wrote: > > > > > XContentBuilder has support for BigDecimal, but: > > > > > > 1. If you pass the source as a Map when indexing, the BigDecimal > > > handling doesn't get invoked ([https://github.com/](https://github.com/) > > > elasticsearch/elasticsearch/issues/5260[https://github.com/elasticsearch/elasticsearch/issues/5260](https://github.com/elasticsearch/elasticsearch/issues/5260) > > > ). > > > 2. The existing handling should delegate through to Jackson's > > > handling of BigDecimal (which can be configured to serialise BigDecimal in > > > a lossless fashion - I dont think that feature existed when I had to worry > > > about it last) > > > > > > Looking at the code now, I think its actually an easy change - I will > > > see if I can create a pull request. > > > > > > -Nick > > > > > > On Wednesday, 26 February 2014 17:28:29 UTC, Jörg Prante wrote: > > > > > > > ES accepts BigDecimal input. You can specify scale and rounding mode to > > > > format the BigDecimal. > > > > > > > > [https://github.com/jprante/elasticsearch/commit/](https://github.com/jprante/elasticsearch/commit/) > > > > 8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec > > > > > > > > Internally, BigDecimal is automatically converted to a JSON string if > > > > the number does not fit into double format. Because numbers are useful in > > > > Lucene for range searches, they have an advantage. > > > > > > > > But I agree, another option could be to enforce string conversion in > > > > any case, for example storing currency values as strings for financial > > > > services, without arithmetic operations in the index. > > > > > > > > Maybe the toEngineeringString() was not a smart decision and > > > > toPlainString() works better. > > > > > > > > So I would welcome improvements, or should I suggest one in a pull > > > > request? > > > > > > > > Jörg > > > > > > > > On Wed, Feb 26, 2014 at 6:05 PM, mooky [nick.mi...@gmail.com](mailto:nick.mi...@gmail.com) wrote: > > > > > > > > > In financial services space, we almost never use float/double in our > > > > > domain - we always use BigDecimal. > > > > > > > > > > In elastic, I would like to be able to index/store BigDecimal in a > > > > > lossless manner (ie what I get back from \_source has the same precision, > > > > > etc as what I put in). > > > > > > > > > > When I have had to preserve the json serialisation of BigDecimal, I > > > > > have usually had custom serialiser/deserialisers that printed it out as a > > > > > json number - but whose textual value was toPlainString(). When > > > > > deserialising, creating the BigDecimal with the string value (e.g. > > > > > '42.5400') maintained the precision that was originally serialised > > > > > e.g. > > > > > > > > > > { > > > > > verySmallNumber : 0.00000000012000, > > > > > otherNumber : 42.5400 > > > > > } > > > > > > > > > > Perhaps elastic could index bigdecimal as a double - but store it in > > > > > the source in a lossless fashion. > > > > > It would require a user setting, I guess, to treat all floating point > > > > > numbers as BigDecimal. > > > > > > > > > > Thoughts? > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac% > > > > > [40googlegroups.com](http://40googlegroups.com). > > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > > > "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an > > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/d56144d1-3e0d-46d2-9ff8-a2cadc9b8344%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/d56144d1-3e0d-46d2-9ff8-a2cadc9b8344%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [March 21, 2014, 10:46am UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/7 "2014-03-21T10:46:00Z")
Trying to submit a pull request. Getting a 403 .... -Nick On Monday, 10 March 2014 17:28:24 UTC, mooky wrote: > Righto - I will try add some. > -Nick > > On Wednesday, 5 March 2014 13:48:58 UTC, Jörg Prante wrote: > > > Yes, there are no tests yet. > > > > Jörg > > > > On Wed, Mar 5, 2014 at 2:24 PM, mooky [nick.mi...@gmail.com](mailto:nick.mi...@gmail.com) wrote: > > > > > I am ready to create a pull request - its actually quite a simple change. > > > However, I cant find \*any \*tests for the existing BigDecimal support > > > ... does that sound right? > > > > > > -Nick > > > > > > On Friday, 28 February 2014 12:09:00 UTC, mooky wrote: > > > > > > > XContentBuilder has support for BigDecimal, but: > > > > > > > > 1. If you pass the source as a Map when indexing, the BigDecimal > > > > handling doesn't get invoked ([https://github.com/](https://github.com/) > > > > elasticsearch/elasticsearch/issues/5260[https://github.com/elasticsearch/elasticsearch/issues/5260](https://github.com/elasticsearch/elasticsearch/issues/5260) > > > > ). > > > > 2. The existing handling should delegate through to Jackson's > > > > handling of BigDecimal (which can be configured to serialise BigDecimal in > > > > a lossless fashion - I dont think that feature existed when I had to worry > > > > about it last) > > > > > > > > Looking at the code now, I think its actually an easy change - I will > > > > see if I can create a pull request. > > > > > > > > -Nick > > > > > > > > On Wednesday, 26 February 2014 17:28:29 UTC, Jörg Prante wrote: > > > > > > > > > ES accepts BigDecimal input. You can specify scale and rounding mode > > > > > to format the BigDecimal. > > > > > > > > > > [https://github.com/jprante/elasticsearch/commit/](https://github.com/jprante/elasticsearch/commit/) > > > > > 8ef8cd149b867e3e45bc3055dfd6da80e4e9c7ec > > > > > > > > > > Internally, BigDecimal is automatically converted to a JSON string if > > > > > the number does not fit into double format. Because numbers are useful in > > > > > Lucene for range searches, they have an advantage. > > > > > > > > > > But I agree, another option could be to enforce string conversion in > > > > > any case, for example storing currency values as strings for financial > > > > > services, without arithmetic operations in the index. > > > > > > > > > > Maybe the toEngineeringString() was not a smart decision and > > > > > toPlainString() works better. > > > > > > > > > > So I would welcome improvements, or should I suggest one in a pull > > > > > request? > > > > > > > > > > Jörg > > > > > > > > > > On Wed, Feb 26, 2014 at 6:05 PM, mooky [nick.mi...@gmail.com](mailto:nick.mi...@gmail.com) wrote: > > > > > > > > > > > In financial services space, we almost never use float/double in our > > > > > > domain - we always use BigDecimal. > > > > > > > > > > > > In elastic, I would like to be able to index/store BigDecimal in a > > > > > > lossless manner (ie what I get back from \_source has the same precision, > > > > > > etc as what I put in). > > > > > > > > > > > > When I have had to preserve the json serialisation of BigDecimal, I > > > > > > have usually had custom serialiser/deserialisers that printed it out as a > > > > > > json number - but whose textual value was toPlainString(). When > > > > > > deserialising, creating the BigDecimal with the string value (e.g. > > > > > > '42.5400') maintained the precision that was originally serialised > > > > > > e.g. > > > > > > > > > > > > { > > > > > > verySmallNumber : 0.00000000012000, > > > > > > otherNumber : 42.5400 > > > > > > } > > > > > > > > > > > > Perhaps elastic could index bigdecimal as a double - but store it in > > > > > > the source in a lossless fashion. > > > > > > It would require a user setting, I guess, to treat all floating point > > > > > > numbers as BigDecimal. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "elasticsearch" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > msgid/elasticsearch/b54dfd5a-3a0e-4946-aa5f-28b3794a92ac% > > > > > > [40googlegroups.com](http://40googlegroups.com). > > > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "elasticsearch" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > To view this discussion on the web visit > > > > > [https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/b8463a21-c997-4269-ae52-992caae88ced%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/f567a7fe-7c41-438d-95a5-3c7415f6b32b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f567a7fe-7c41-438d-95a5-3c7415f6b32b%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [March 22, 2014, 12:31am UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/8 "2014-03-22T00:31:33Z")
Fixed. Pull request here: [https://github.com/elasticsearch/elasticsearch/pull/5491](https://github.com/elasticsearch/elasticsearch/pull/5491) -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/84755e75-13f2-4f80-894f-b88452a8de68%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/84755e75-13f2-4f80-894f-b88452a8de68%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [May 7, 2014, 2:18pm UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/9 "2014-05-07T14:18:51Z")
There is a more complete pull request here: [BigInteger/BigDecimal support by jprante · Pull Request #5683 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/pull/5683) On Saturday, 22 March 2014 00:31:33 UTC, mooky wrote: > Fixed. Pull request here: > [Add support for lossless storage of BigDecimal numeric values in \_source by nickminutello · Pull Request #5491 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/pull/5491) -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/84dad4e7-4935-4349-99c6-a0d3c355c7b5%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/84dad4e7-4935-4349-99c6-a0d3c355c7b5%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:31am UTC](https://discuss.elastic.co/t/bigdecimal-support/16040/10 "2017-07-06T01:31:04Z")