Hi David, everyone I thought I'd set about changing pretty much all the doubles in the accounting component to BigDecimal and I've got a couple of questions: 1. Do we need to follow the standard path we've taken in the past where we deprecate any methods taking or returning doubles and add Bd to the end of a new BigDecimal version? I guess we do but it's going to take a longer so I figure no harm in asking.
2. Slightly OT but I can't see the point of the scaled and rounded ZEROs in the java files, could someone explain the advantage of them over BigDecimal.ZERO? 3. Could someone give me an example of when to use floating-point/double over fixed-point/BigDecimal? I'm not 100% sure of that one. Thanks Scott 2008/10/22 David E Jones <[EMAIL PROTECTED]>: > > I've created a branch, now available at: > > https://svn.apache.org/repos/asf/ofbiz/branches/typecheckcleanup200810 > > The branch split was revision 706867, so we can merge from the trunk at that > rev going forward, and eventually merge back into the trunk once we're > comfortable that enough things have been tested by running, perhaps using a > bunch of the automated tests too (not sure how well those run in the trunk > right now though, ie I haven't run them in quite some time!). > > Anyway, the main initial process that I targeted was ecommerce browsing, add > to cart, and checkout/order. Still need to test basic things like order > fulfillment, purchasing and receiving, and tons of other stuff, but > hopefully most other things won't be impacted as much. > > Any and all help is appreciated! > > -David > > NOTE: I'm still checking out the branch and applying my patch with the work > so far, so it'll be a few minutes before that's in. > > On Oct 21, 2008, at 10:20 PM, Scott Gray wrote: > >> +1 for making the changes and I'm happy to help with the mundane stuff. >> >> Regards >> Scott >> >> 2008/10/22 David E Jones <[EMAIL PROTECTED]>: >>> >>> I added some stuff to make the warnings from entity field type checks a >>> bit >>> more prominent, and include a stack trace to make them easier to track >>> down. >>> I tried throwing exceptions instead of the warning log messages but that >>> pretty much breaks everything, especially because we have lots of >>> BigDecimal/Double problems... >>> >>> On the BigDecimal versus Double stuff, one of the main type change >>> problems >>> comes from this old issue. To help resolve this I'd like to change the >>> java-type of currency-amount and currency-precise to BigDecimal instead >>> of >>> Double. >>> >>> It doesn't make sense to change the "floating-point" type's java-type to >>> BigDecimal, because it really is a floating point like a Double. However, >>> we >>> also have many fields that need decimal precision but really should be >>> fixed >>> point and not floating point... but they really aren't "currency". For >>> these >>> I propose to add a "fixed-point" field type. This would have a BigDecimal >>> java-type and in the database should have a type that is also fixed point >>> (ie not DOUBLE or FLOAT), unless the database has no fixed point types >>> (which is a big minus for those databases). Also, the floating-point type >>> should have a Double java-type and a floating point SQL type. >>> >>> One side effect to changing the java-type on these field types is that it >>> changes services definitions that are based on entity definitions, which >>> causes the service engine to throw exceptions for type checks... and it >>> does >>> throw exceptions instead of just printing warning messages, so it does >>> break >>> stuff when doing that. >>> >>> This is a change that we can't switch back and forth on. Either all of >>> these >>> services take a Double typed parameters, or BigDecimal typed ones... and >>> never some of each. >>> >>> Because of this I'm actually tempted to do a branch and get the changes >>> going. I'm paying with a few common processes with this in place right >>> now. >>> >>> Any thoughts related to this would be appreciated. >>> >>> Checking types... what a can of worms! >>> >>> -David >>> >>> >>> > >
