Anything done to move it along is okay with me. I spent a day on steps 1 and 3 that I proposed. I couldn't get the code to work right away and I needed to get other things done, so I stopped working on it. I could post a patch if anyone wants to take a stab at it.
-Adrian --- On Sun, 10/19/08, David E Jones <[EMAIL PROTECTED]> wrote: > From: David E Jones <[EMAIL PROTECTED]> > Subject: Re: Automatic Type Conversion for GenericEntity/Value.set (was Re: > Revision 703731) > To: dev@ofbiz.apache.org > Date: Sunday, October 19, 2008, 1:54 AM > 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 > >>>> > >>> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
