Re: [flexcoders] Re: decimal numbers in financial applications

Thu, 17 Aug 2006 13:13:42 -0700

Matt,
I am sorry, I must be missing something simple. I was suggesting not to use BigDecimal on the server and deal straight with double on both sides. Apparently you acknowledge that it would work but need to keep BigDecimal for other reasons. I am wondering about other data types that are produced by VRUD framework you are using. Are the dates produced from  sql or utils package - would be the next question. That is one of the reasons for us to create Flex specific CRUD framework ( http://www.adobe.com/devnet/flex/articles/daoflex.html) so the marshalling issues are eliminated  
 
If that is the case, your options are really limited. You obviously requested Adobe to look into the issue and , if you logged the error, you usually get confirmation within few days that it has or has not been recreated and some indication on the release timeframe.
 
If for whatever reason you need to fix protocol and need to deal with that now, here is anothe roption. For custom datatypes, I would build trivial gateway for FDS. Here is a post for unsecured remoting (simple AMF, not FDS) gateway I use to batch/transact unregistered requests ( http://www.faratasystems.com/?p=7) . You could relatively simply (50-100 lines of Java code the last time we had to do similar "patch")  set up either filter or similar gateway and do rounding there.
 
Given a choice, I would replace BigDecimal with double in CRUD level and let DB do the truncation.
 
Sincerely,
Anatole
 
On 8/17/06, busitech <[EMAIL PROTECTED]> wrote:

> In case of Actionscript double
(1.9199999999999999289457264239899814128875732421875
> from the original post) it is $500 billion.

Hi Anatole,

Did you note that FDS _truncates_ the actionscript double when
converting to BigDecimal? The extra information is lost in FDS.

So in this case, when the tax rate keyed in at the client is off by
.01%, this works out to be a 10 cent mistake on a $1,000 transaction.

This problem would present itself any time the user is keying in a
price on the client side, trying to save the data. Imagine a user
doing a price change on thousands of items, hitting save, and watching
hours of work disappear...

You're right - letting the DB driver do the rounding would work if we
had a separate DTO for each domain object where we could put the
floating point number temporarily. Since we're using EJB 3.0, which
is an excellent abstract persistence layer, we are able to allow the
POJO entity to become the DTO, and thus our serialization framework
(Flex) must either be fixed (by Adobe) to round correctly, or extended
(a new serializable type class).

So for us the immediate answer is to create a serializable BigDecimal
in Actionscript which can pass through the protocol layer unscathed
and give exact results on the client. This not only provides a fix
for the persistence problem, but also allows the client to compute
things without help from the server, and display them confidently to
the user, knowing that when the server performs the same calculation,
it will match exactly.

Best regards,

Matt


__._,_.___

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




SPONSORED LINKS
Software development tool Software development Software development services
Home design software Software development company

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to