I was thinking that there may not be too many of these, but after
playing around with it I now know I was wrong!
There will be quite a few, many caused by the Double/BigDecimal issue,
but probably many others that are related to a String being passed in
where another object is needed (ie to represent the parsed string).
We could do some stuff for Double vs BigDecimal. Right now I'm
thinking that maybe we should change all fieldtype*.xml files to refer
to BigDecimal instead of Double so that all warnings (or future
exceptions) will push us toward BigDecimal instead of Double.
Any thoughts for/against that? We can change the fieldtype*.xml files
without causing any problems right now (or it shouldn't anyway...).
-David
On Oct 15, 2008, at 10:36 AM, Adrian Crum wrote:
I spent some time looking through the entity condition code and I
don't think it is possible to set up a mismatched data type warning
in the log.
Here's what I'm thinking:
1. Add a method to EntityUtil that will accept a Map, a
GenericDelegator, an entity name, a Locale, and a TimeZone. The
method would go through the Map and convert the Map values to the
correct types.
2. Go through the *.java and *.groovy files and have them use the
new utility method where applicable.
3. Go through the simple method and screen widget code that
constructs entity conditions and have those bits of code convert
data types before constructing the entity conditions.
This won't catch all of the potential problems, but it should cover
most of them.
Let me know what you think.
-Adrian
Adrian Crum wrote:
We could add a warning message to the EntityCondition classes (like
the one on line 411 of GenericEntity.java), then start checking the
logs for the warning messages.
-Adrian
Scott Gray wrote:
Thanks Adrian, I understand the implications now.
So what's the next step, should we add type checking to the
EntityConditions and then perhaps only enforce the correct types on
some volunteer machines until we can fix a good portion of the
problem
code and then move it to the trunk?
Regards
Scott
2008/10/15 Adrian Crum <[EMAIL PROTECTED]>:
Scott Gray wrote:
Ok it makes more sense to me now, conversion needs to take place
at a
level where the relevant information is still available so doing
it on
a low level isn't really an option (even though that's been
allowed to
happen up until now). I guess I was having trouble
understanding why
we needed to do all this work when everything had been running
fine,
but I see now that it wasn't really running that fine.
To be precise, some things in OFBiz have not been running fine
since
September 2006 - https://issues.apache.org/jira/browse/OFBIZ-221.
-Adrian
