Adrian Crum wrote: > Adam Heath wrote: >> David E Jones wrote: >>> On Feb 24, 2010, at 2:01 PM, Adam Heath wrote: >>> >>>> David E Jones wrote: >>>>> On Feb 24, 2010, at 1:41 PM, Adam Heath wrote: >>>>> >>>>>> Adam Heath wrote: >>>>>>> David E Jones wrote: >>>>>>>> An update on this problem: It looks like it is another time zone >>>>>>>> issue, or in other words another spot that doesn't manage time >>>>>>>> zones consistently (I won't say correctly, because I'm not sure >>>>>>>> if that applies here... partly because I'm not sure if I like >>>>>>>> the way that OFBiz handles time zones right now). >>>>>>>> >>>>>>>> In any case, for demonstration purposes here is code that works: >>>>>>>> >>>>>>>> <set field="fromDate" from-field="parameters.fromDate" >>>>>>>> type="Timestamp"/> >>>>>>>> <entity-one entity-name="ProductFeatureAndAppl" >>>>>>>> value-field="productFeatureAndAppl" auto-field-map="false"> >>>>>>>> <field-map field-name="productId" >>>>>>>> from-field="parameters.productId"/> >>>>>>>> <field-map field-name="productFeatureId" >>>>>>>> from-field="parameters.productFeatureId"/> >>>>>>>> <field-map field-name="fromDate" from-field="fromDate"/> >>>>>>>> </entity-one> >>>>>>>> >>>>>>>> Here is code that does not work, but should: >>>>>>>> >>>>>>>> <entity-one entity-name="ProductFeatureAndAppl" >>>>>>>> value-field="productFeatureAndAppl" auto-field-map="false"> >>>>>>>> <field-map field-name="productId" >>>>>>>> from-field="parameters.productId"/> >>>>>>>> <field-map field-name="productFeatureId" >>>>>>>> from-field="parameters.productFeatureId"/> >>>>>>>> <field-map field-name="fromDate" >>>>>>>> from-field="parameters.fromDate"/> >>>>>>>> </entity-one> >>>>>>> At a guess, <field-map> is converting the value to a String, then >>>>>>> taking that and converting it back to the correct object, based >>>>>>> on the >>>>>>> entity model definition. It shouldn't do this conversion at all. >>>>>>> >>>>>>> Upon looking at entity/finder/*, I see lots of instances of FSE; >>>>>>> this >>>>>>> means there is the same problem as I discovered previously, you >>>>>>> can't >>>>>>> fetch anything but strings using FSE. >>>>>>> >>>>>>> I have a feature implemented to fix that, but it's not quite >>>>>>> correct, >>>>>>> as it doesn't handle nulls very well(might be the reponsibility >>>>>>> of the >>>>>>> calling location to auto-convert null to ""). >>>>>>> >>>>>> Yeah, exactly this. EntityFinderUtil.expandFieldMapToContact calls >>>>>> FSE.expandString, when evaluating the fieldMap. That is the bug, >>>>>> pure >>>>>> and simple. >>>>> As interesting as your ideas are about how things should work, that >>>>> isn't the problem here. >>>> Um, converting the passed value to a string, then converting it back, >>>> is not a problem? >>> I don't know if it's a "problem" or not. My point is, it has >>> absolutely nothing to do with the problem I brought up here, in that >>> no change made there could fix the problem that this thread is about. >>> >>> I'll write more in response to Adrian's comments. >> >> As Adrian said, this could be two problems, which I can agree with. >> >> Doing a conversion to String, then back, it obviously not a good >> thing. Causes more work, which sucks. >> >> However, I'm going with you, in that this *did* work in the past. I'm >> going to go with my gut, and say that EntityFinderUtil's use of FSE >> hasn't changed, so the Object->String->Object conversion path has been >> altered. > > An example of what *could* go wrong: service parameter -> Object uses > user's time zone, then Object -> entity field doesn't use the user's > time zone. > > I have a possible solution that I'll propose in my response to David's > response to my comments. ;-)
Last night I thought about writing test cases against UtilObject.simpleTypeConvert, before the conversion system was put in place.
