Unless someone has objections, then yes, let's go for it. This is not
backward compatible, but that is true of many of these Double-
>BigDecimal changes and we've already discussed it.
-David
On Feb 1, 2009, at 10:33 AM, Bilgin Ibryam wrote:
Thanks for the advice David, it seems even easier:
Then I will change originalValue and convertedValue fields from
Double to BigDecimal in convertUom and convertUomCustom. Is it what
you had in mind ?
On Feb 1, 2009, at 7:53 PM, David E Jones wrote:
Actually (IMO) we should change the service to not use Double at
all and instead always use BigDecimal. It causes problems to use
Double for calculations on BigDecimal numbers, but it is okay to
use BigDecimal on Double numbers in any case we're likely to run
into.
Is this something you're working on? If so, that's great...
-David
On Feb 1, 2009, at 9:43 AM, Bilgin Ibryam wrote:
Hi devs,
I noticed that convertUom service accept Double and returns Double
value(and it is correct as UomConversation.conversationFactor is
with type Double). But all the code using convertUom service is
already using BigDecimals and not working.
The solution seems to be to convert BigDecimals to Double before
invoking convertUom, and then convert the Double from result to
BigDecimal...
But, I wanted to ask is it a good idea to add also optional
BigDecimal INOUT parameter to convertUom service so we can use it
directly with BigDecimals?
Bilgin