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
