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
