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. Inside Converters, there are methods to fetch the locale/timezone from the context. I'm guessing those are not compatible with the previous method of this Object->String->Object conversion.
