Firstly and without verifying, the automatic conversion sounds wrong and yes I'm quite sure it intentional never used to be that way.
Secondly, I'm not sure why quantityToProduce is a floating point instead of a fixed point data type. I'm surprised and can't imagine why I skipped these when I was doing the double -> BigDecimal conversion of everything. Regards Scott On 14/04/2010, at 6:50 AM, Bob Morley wrote: > We have just started to make use of ProductionRun in our project and we were > having a problem in the create because the ProductionRunServices (around > line 274) makes a call to "createWorkEffort" using a "quantityToProduce" > that is a BigDecimal. The field on the WorkEffort entity is actually a > Double, so in our solution it was causing a "bad type error" and failing. > > I jumped to trunk to try to figure out why it was working in stock Ofbiz. > After some digging, it turns out that the conversion enhancements now > (appear to) silently do this conversion, resulting in a context that > contains that field as a Double. > > This happens because the ServiceDispatcher's runSync method calls > "checkAuth" which (if the user can call the service) calls > ModelService.makeValid which ultimately calls ObjectType.simpleTypeConvert > that handles the BigDecimal -> Double conversion. > > Is this the intended behavior? To be honest, it seems to me that the > complaint that the parameter was not the proper data type was more > desirable. I understand that when we are handling a postback, values need > to be converted from String to their desired types; but if I am making a > call in our back-end to another service I would think I should be forced to > adhere to that service definition's signature. > -- > View this message in context: > http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-tp1838891p1838891.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
smime.p7s
Description: S/MIME cryptographic signature
