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/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 >> >> 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> 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. >>> To view this discussion on the web visit >>> 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. >>> >> >> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit 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.
