You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <de...@me.com> on 2010/02/24 05:32:31 UTC
entity-one no longer converting types (probably a
GenericEntity.setAllFields issue)
Has anyone made any changes GenericEntity.setAllFields method or the code underneath it? It no longer works unless the primary key consists only of String type fields.
This is easy to reproduce, even in the Example Application, by trying to work with ExampleFeatureAppl records, which have a fromDate as part of the primary key.
This warning is showing, and the underlying code does not work (on MySQL at least):
[java] 2010-02-23 21:22:42,706 (http-0.0.0.0-8443-1) [ GenericEntity.java:422:WARN ]
[java] ---- exception report ----------------------------------------------------------
[java] =-=-=-=-=-=-=-=-= Database type warning GenericEntity.set =-=-=-=-=-=-=-=-= In entity field [ProductFeatureAndAppl.fromDate] set the value passed in [java.lang.String] is not compatible with the Java type of the field [java.sql.Timestamp]
[java] Exception: java.lang.Exception
[java] Message: Location of database type warning
[java] ---- stack trace ---------------------------------------------------------------
[java] java.lang.Exception: Location of database type warning
[java] org.ofbiz.entity.GenericEntity.set(GenericEntity.java:422)
[java] org.ofbiz.entity.GenericEntity.set(GenericEntity.java:368)
[java] org.ofbiz.entity.GenericEntity.setAllFields(GenericEntity.java:885)
[java] org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:105)
[java] org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:81)
[java] org.ofbiz.widget.screen.ModelScreenAction$EntityOne.runAction(ModelScreenAction.java:523)
-David
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> On Feb 24, 2010, at 3:01 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> On Feb 24, 2010, at 1:15 PM, Adrian Crum wrote:
>>>> David E Jones wrote:
>>>>> I'm wondering though: how many more places are not handling the time zone correctly? Is there a better way to manage things when the user's time zone setting is different from the server's? Right now it's a mess...
>>>> This will be a worthwhile discussion - because handling time zones correctly hasn't been discussed before. First off: What does handling them correctly mean?
>>>>
>>>> Right now, the process is to try to use the user's time zone if it is available, otherwise use the default. There is no strategy or enforcement of a set of rules - so it isn't surprising that there are inconsistencies.
>>> I'll step back first and describe briefly what the goal of time zone support seems to be: let the user see all times in their own time zone regardless of the server's time zone. This is complicated because when the server converts a Timestamp (or java.util.Date) to a String it does so with either the server's time zone (by default), or by the user's time zone if we do that explicitly. When a Timestamp String comes from a user, whether it be something the user entered by hand or something that is a parameter that is just passed through the browser to another request (in a URL parameter or a hidden form field), the server can interpret that in the user's time zone if there is one, or in the server's time zone by default. In other words, these String representations of Timestamps passed through the browser need to be interpreted consistently because they do not carry time zone information with them (ie they are not like the Timestamp internal representation which is a relat
ive time from a constant point in time, in the GMT time zone so there is no confusion).
>>> So, we have consistency problems on two sides:
>>> 1. producing timestamp Strings for users to, or for the browser to pass back to the system in a URL parameter or hidden field
>>> 2. interpreting timestamp Strings in HTTP requests, from form fields or URL parameters
>>> On both sides we have issues where changing between String value and Timestamp object may be done in the server's time zone or the user's time zone.
>>> It would be nice if all of the code that produced the Strings or consumed them was consistent, but it is spread all over and not consistent.
>> Plus, how do you specify a time zone and where? What if you have multi-tenancy running on a single OFBiz instance and each tenant (or store) wants to appear to be in a different time zone? That's even more complicated than server versus user time zones.
>>
>> The fundamental problem is there is no direct relation of any given Timestamp to any TimeZone.
>
> That's not correct. The Timestamp object has an internal representation that is relative to GMT. Or, more to the point, the internal representation is just a long that is relative to a certain point in time so time zone doesn't matter.
>
> The problem comes into play when you want to convert it to or from a string that consists of things like days and hours.
Exactly. Like I said: "The fundamental problem is there is no direct
relation of any given Timestamp to any TimeZone." You have to have
*both* to convert a Timestamp to a String.
You have a Timestamp instance in your hand and you need to convert it to
a String. What time zone do you use? Who knows? There isn't enough
information in the data type to do the conversion.
>>> So, how to fix it:
>>> 1. more testing where the user's time zone is different from the server's, and fix one problem at a time
>>> 2. try to introduce some sort of time zone value in timestamp String representations so that we know what the time zone is instead of trying to stay consistent with either the user's time zone or the server's
>>> 3. refactor all Timestamp code deal with #1 or #2 above to go through a single spot and do the time zone compensation consistently
>> 4. Use stronger typing. Create a LocalizedDate class and pass that around instead of a plain Date or Timestamp. Then it will be clear what the intention is. A plain Timestamp would imply the server's time zone.
>
> And how do we pass this object in a URL parameter, or in a hidden HTML form field?
The conversion framework will take care of that. It might be better to
think about application scenarios.
Scenario 1: A user types a date/time into a data entry field and clicks
Submit. The application's design specifies the date/time is referenced
to the user's time zone. So, the date/time string is combined with the
user's time zone in a LocalizedDate and that object is passed around the
framework. The framework code doesn't have to guess what time zone to
use for conversions - because the time zone is included in the
LocalizedDate.
Scenario 2: A Timestamp entity field needs to be displayed. The
application's design specifies the Timestamp is referenced to the
server's time zone. The Timestamp field is combined with the server's
time zone in a LocalizedDate and that object is passed around the
framework. The framework code doesn't have to guess what time zone to
use for conversions - because the time zone is included in the
LocalizedDate.
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
On Feb 24, 2010, at 3:01 PM, Adrian Crum wrote:
> David E Jones wrote:
>> On Feb 24, 2010, at 1:15 PM, Adrian Crum wrote:
>>> David E Jones wrote:
>>>> I'm wondering though: how many more places are not handling the time zone correctly? Is there a better way to manage things when the user's time zone setting is different from the server's? Right now it's a mess...
>>> This will be a worthwhile discussion - because handling time zones correctly hasn't been discussed before. First off: What does handling them correctly mean?
>>>
>>> Right now, the process is to try to use the user's time zone if it is available, otherwise use the default. There is no strategy or enforcement of a set of rules - so it isn't surprising that there are inconsistencies.
>> I'll step back first and describe briefly what the goal of time zone support seems to be: let the user see all times in their own time zone regardless of the server's time zone. This is complicated because when the server converts a Timestamp (or java.util.Date) to a String it does so with either the server's time zone (by default), or by the user's time zone if we do that explicitly. When a Timestamp String comes from a user, whether it be something the user entered by hand or something that is a parameter that is just passed through the browser to another request (in a URL parameter or a hidden form field), the server can interpret that in the user's time zone if there is one, or in the server's time zone by default. In other words, these String representations of Timestamps passed through the browser need to be interpreted consistently because they do not carry time zone information with them (ie they are not like the Timestamp internal representation which is a relative time from a constant point in time, in the GMT time zone so there is no confusion).
>> So, we have consistency problems on two sides:
>> 1. producing timestamp Strings for users to, or for the browser to pass back to the system in a URL parameter or hidden field
>> 2. interpreting timestamp Strings in HTTP requests, from form fields or URL parameters
>> On both sides we have issues where changing between String value and Timestamp object may be done in the server's time zone or the user's time zone.
>> It would be nice if all of the code that produced the Strings or consumed them was consistent, but it is spread all over and not consistent.
>
> Plus, how do you specify a time zone and where? What if you have multi-tenancy running on a single OFBiz instance and each tenant (or store) wants to appear to be in a different time zone? That's even more complicated than server versus user time zones.
>
> The fundamental problem is there is no direct relation of any given Timestamp to any TimeZone.
That's not correct. The Timestamp object has an internal representation that is relative to GMT. Or, more to the point, the internal representation is just a long that is relative to a certain point in time so time zone doesn't matter.
The problem comes into play when you want to convert it to or from a string that consists of things like days and hours.
>> So, how to fix it:
>> 1. more testing where the user's time zone is different from the server's, and fix one problem at a time
>> 2. try to introduce some sort of time zone value in timestamp String representations so that we know what the time zone is instead of trying to stay consistent with either the user's time zone or the server's
>> 3. refactor all Timestamp code deal with #1 or #2 above to go through a single spot and do the time zone compensation consistently
>
> 4. Use stronger typing. Create a LocalizedDate class and pass that around instead of a plain Date or Timestamp. Then it will be clear what the intention is. A plain Timestamp would imply the server's time zone.
And how do we pass this object in a URL parameter, or in a hidden HTML form field?
-David
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> On Feb 24, 2010, at 1:15 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> I'm wondering though: how many more places are not handling the time zone correctly? Is there a better way to manage things when the user's time zone setting is different from the server's? Right now it's a mess...
>> This will be a worthwhile discussion - because handling time zones correctly hasn't been discussed before. First off: What does handling them correctly mean?
>>
>> Right now, the process is to try to use the user's time zone if it is available, otherwise use the default. There is no strategy or enforcement of a set of rules - so it isn't surprising that there are inconsistencies.
>
> I'll step back first and describe briefly what the goal of time zone support seems to be: let the user see all times in their own time zone regardless of the server's time zone. This is complicated because when the server converts a Timestamp (or java.util.Date) to a String it does so with either the server's time zone (by default), or by the user's time zone if we do that explicitly. When a Timestamp String comes from a user, whether it be something the user entered by hand or something that is a parameter that is just passed through the browser to another request (in a URL parameter or a hidden form field), the server can interpret that in the user's time zone if there is one, or in the server's time zone by default.
>
> In other words, these String representations of Timestamps passed through the browser need to be interpreted consistently because they do not carry time zone information with them (ie they are not like the Timestamp internal representation which is a relative time from a constant point in time, in the GMT time zone so there is no confusion).
>
> So, we have consistency problems on two sides:
>
> 1. producing timestamp Strings for users to, or for the browser to pass back to the system in a URL parameter or hidden field
>
> 2. interpreting timestamp Strings in HTTP requests, from form fields or URL parameters
>
> On both sides we have issues where changing between String value and Timestamp object may be done in the server's time zone or the user's time zone.
>
> It would be nice if all of the code that produced the Strings or consumed them was consistent, but it is spread all over and not consistent.
Plus, how do you specify a time zone and where? What if you have
multi-tenancy running on a single OFBiz instance and each tenant (or
store) wants to appear to be in a different time zone? That's even more
complicated than server versus user time zones.
The fundamental problem is there is no direct relation of any given
Timestamp to any TimeZone.
>
> So, how to fix it:
>
> 1. more testing where the user's time zone is different from the server's, and fix one problem at a time
>
> 2. try to introduce some sort of time zone value in timestamp String representations so that we know what the time zone is instead of trying to stay consistent with either the user's time zone or the server's
>
> 3. refactor all Timestamp code deal with #1 or #2 above to go through a single spot and do the time zone compensation consistently
4. Use stronger typing. Create a LocalizedDate class and pass that
around instead of a plain Date or Timestamp. Then it will be clear what
the intention is. A plain Timestamp would imply the server's time zone.
-Adrian
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
On Feb 24, 2010, at 3:00 PM, Adam Heath wrote:
>>
>> I'll step back first and describe briefly what the goal of time zone support seems to be: let the user see all times in their own time zone regardless of the server's time zone. This is complicated because when the server converts a Timestamp (or java.util.Date) to a String it does so with either the server's time zone (by default), or by the user's time zone if we do that explicitly. When a Timestamp String comes from a user, whether it be something the user entered by hand or something that is a parameter that is just passed through the browser to another request (in a URL parameter or a hidden form field), the server can interpret that in the user's time zone if there is one, or in the server's time zone by default.
>>
>> In other words, these String representations of Timestamps passed through the browser need to be interpreted consistently because they do not carry time zone information with them (ie they are not like the Timestamp internal representation which is a relative time from a constant point in time, in the GMT time zone so there is no confusion).
>>
>> So, we have consistency problems on two sides:
>>
>> 1. producing timestamp Strings for users to, or for the browser to pass back to the system in a URL parameter or hidden field
>>
>> 2. interpreting timestamp Strings in HTTP requests, from form fields or URL parameters
>>
>> On both sides we have issues where changing between String value and Timestamp object may be done in the server's time zone or the user's time zone.
>>
>> It would be nice if all of the code that produced the Strings or consumed them was consistent, but it is spread all over and not consistent.
>>
>> So, how to fix it:
>>
>> 1. more testing where the user's time zone is different from the server's, and fix one problem at a time
>>
>> 2. try to introduce some sort of time zone value in timestamp String representations so that we know what the time zone is instead of trying to stay consistent with either the user's time zone or the server's
>>
>> 3. refactor all Timestamp code deal with #1 or #2 above to go through a single spot and do the time zone compensation consistently
>>
>> I'm not sure about any of these solutions, ie none of them stand out as the obvious answer. No matter what we do, we have to figure out a way to make this more consistent so that code all over doesn't need to worry about it. In other words, we do it in the UI layer as centrally as possible. We have a problem right now though where the code is spread all over and even if we go with something that automatically handles this for HTML output and HTTP input then we'd have to remove time zone
>> handling everywhere else (lest the time zone compensation be done twice and we end up skewed the other way).
>>
>> For now, I guess I'm going with solution #1 since that is the direction the project is already moving in.
>>
>> -David
>
> The server has no time zone. It's all the user's timezone(and locale,
> really). The server should always deal with values that don't carry
> any explicit timezone/locale/color/size constraints. Those are purely
> needed for front-end representation.
The server has not time zone? Then how does it decide on the internal representation for the following:
Timestamp.valueOf("2010-02-23 12:00:00.000");
That's just a date and time with no time zone... how does it figure out how many milliseconds are between that date/time and the epoch time point (January 1, 1970, 00:00:00 GMT)?
I'll restate the assertion that any running JVM has a default time zone setting. For an example check out the TimeZone.getDefault() method.
> This would mean that entity xml data has to encode the internal
> timestamp value, or a string version that includes a timezone. It
> should throw an exception if there is no timezone when converting from
> a String.
>
> Maybe introduce a new object, UserStringValue, that contains a String,
> and whatever other identifying information is required. Then, the
> conversion system could convert that to Timestamp, Date, currency, etc.
A new object won't help. The Timestamp object is just fine. The problem is in converting to/from String representations of the date/time.
Yes, a string representation that always includes a time zone is an interesting idea (which part of my #2 possible solution). We would still need to support the case where we want to allow the user to manually enter a time or date/time without explicitly saying what the time zone is, but for URL parameters and hidden form fields that have values generated by the system this would be fine.
-David
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adam Heath <do...@brainfood.com>.
>
> I'll step back first and describe briefly what the goal of time zone support seems to be: let the user see all times in their own time zone regardless of the server's time zone. This is complicated because when the server converts a Timestamp (or java.util.Date) to a String it does so with either the server's time zone (by default), or by the user's time zone if we do that explicitly. When a Timestamp String comes from a user, whether it be something the user entered by hand or something that is a parameter that is just passed through the browser to another request (in a URL parameter or a hidden form field), the server can interpret that in the user's time zone if there is one, or in the server's time zone by default.
>
> In other words, these String representations of Timestamps passed through the browser need to be interpreted consistently because they do not carry time zone information with them (ie they are not like the Timestamp internal representation which is a relative time from a constant point in time, in the GMT time zone so there is no confusion).
>
> So, we have consistency problems on two sides:
>
> 1. producing timestamp Strings for users to, or for the browser to pass back to the system in a URL parameter or hidden field
>
> 2. interpreting timestamp Strings in HTTP requests, from form fields or URL parameters
>
> On both sides we have issues where changing between String value and Timestamp object may be done in the server's time zone or the user's time zone.
>
> It would be nice if all of the code that produced the Strings or consumed them was consistent, but it is spread all over and not consistent.
>
> So, how to fix it:
>
> 1. more testing where the user's time zone is different from the server's, and fix one problem at a time
>
> 2. try to introduce some sort of time zone value in timestamp String representations so that we know what the time zone is instead of trying to stay consistent with either the user's time zone or the server's
>
> 3. refactor all Timestamp code deal with #1 or #2 above to go through a single spot and do the time zone compensation consistently
>
> I'm not sure about any of these solutions, ie none of them stand out as the obvious answer. No matter what we do, we have to figure out a way to make this more consistent so that code all over doesn't need to worry about it. In other words, we do it in the UI layer as centrally as possible. We have a problem right now though where the code is spread all over and even if we go with something that automatically handles this for HTML output and HTTP input then we'd have to remove time zone
> handling everywhere else (lest the time zone compensation be done twice and we end up skewed the other way).
>
> For now, I guess I'm going with solution #1 since that is the direction the project is already moving in.
>
> -David
The server has no time zone. It's all the user's timezone(and locale,
really). The server should always deal with values that don't carry
any explicit timezone/locale/color/size constraints. Those are purely
needed for front-end representation.
This would mean that entity xml data has to encode the internal
timestamp value, or a string version that includes a timezone. It
should throw an exception if there is no timezone when converting from
a String.
Maybe introduce a new object, UserStringValue, that contains a String,
and whatever other identifying information is required. Then, the
conversion system could convert that to Timestamp, Date, currency, etc.
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
On Feb 24, 2010, at 1:15 PM, Adrian Crum wrote:
> David E Jones wrote:
>> I'm wondering though: how many more places are not handling the time zone correctly? Is there a better way to manage things when the user's time zone setting is different from the server's? Right now it's a mess...
>
> This will be a worthwhile discussion - because handling time zones correctly hasn't been discussed before. First off: What does handling them correctly mean?
>
> Right now, the process is to try to use the user's time zone if it is available, otherwise use the default. There is no strategy or enforcement of a set of rules - so it isn't surprising that there are inconsistencies.
I'll step back first and describe briefly what the goal of time zone support seems to be: let the user see all times in their own time zone regardless of the server's time zone. This is complicated because when the server converts a Timestamp (or java.util.Date) to a String it does so with either the server's time zone (by default), or by the user's time zone if we do that explicitly. When a Timestamp String comes from a user, whether it be something the user entered by hand or something that is a parameter that is just passed through the browser to another request (in a URL parameter or a hidden form field), the server can interpret that in the user's time zone if there is one, or in the server's time zone by default.
In other words, these String representations of Timestamps passed through the browser need to be interpreted consistently because they do not carry time zone information with them (ie they are not like the Timestamp internal representation which is a relative time from a constant point in time, in the GMT time zone so there is no confusion).
So, we have consistency problems on two sides:
1. producing timestamp Strings for users to, or for the browser to pass back to the system in a URL parameter or hidden field
2. interpreting timestamp Strings in HTTP requests, from form fields or URL parameters
On both sides we have issues where changing between String value and Timestamp object may be done in the server's time zone or the user's time zone.
It would be nice if all of the code that produced the Strings or consumed them was consistent, but it is spread all over and not consistent.
So, how to fix it:
1. more testing where the user's time zone is different from the server's, and fix one problem at a time
2. try to introduce some sort of time zone value in timestamp String representations so that we know what the time zone is instead of trying to stay consistent with either the user's time zone or the server's
3. refactor all Timestamp code deal with #1 or #2 above to go through a single spot and do the time zone compensation consistently
I'm not sure about any of these solutions, ie none of them stand out as the obvious answer. No matter what we do, we have to figure out a way to make this more consistent so that code all over doesn't need to worry about it. In other words, we do it in the UI layer as centrally as possible. We have a problem right now though where the code is spread all over and even if we go with something that automatically handles this for HTML output and HTTP input then we'd have to remove time zone
handling everywhere else (lest the time zone compensation be done twice and we end up skewed the other way).
For now, I guess I'm going with solution #1 since that is the direction the project is already moving in.
-David
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> I'm wondering though: how many more places are not handling the time zone correctly? Is there a better way to manage things when the user's time zone setting is different from the server's? Right now it's a mess...
This will be a worthwhile discussion - because handling time zones
correctly hasn't been discussed before. First off: What does handling
them correctly mean?
Right now, the process is to try to use the user's time zone if it is
available, otherwise use the default. There is no strategy or
enforcement of a set of rules - so it isn't surprising that there are
inconsistencies.
-Adrian
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adam Heath <do...@brainfood.com>.
David E Jones wrote:
> We should probably continue discussing this topic, but FYI the particular problem I found was caused be a bug in the PrimaryKeyFinder code in the way it was setting up the context for the conversion routine. The lower level code was assuming it would be in the context, but the context had already been reduced to just the fields needed for the query.
>
> A fix is in rev 916055.
I see what you did there, and it makes sense. How did this work
before the conversion system was created, when FSE and FMA were being
used, both of which eventually end up calling
ObjectType.simpleTypeConvert? Did you investigate that far? I'm curious.
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
We should probably continue discussing this topic, but FYI the particular problem I found was caused be a bug in the PrimaryKeyFinder code in the way it was setting up the context for the conversion routine. The lower level code was assuming it would be in the context, but the context had already been reduced to just the fields needed for the query.
A fix is in rev 916055.
-David
On Feb 24, 2010, at 1:05 PM, 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>
>
> This also does not work, but should:
>
> <entity-one entity-name="ProductFeatureAndAppl" value-field="productFeatureAndAppl" auto-field-map="true"/>
>
> The problem turns out to not be with the data type, but with the time zone being treated differently in different cases.
>
> I'll work on getting both of these to do the server-side time zone compensation the same as the first one.
>
> I'm wondering though: how many more places are not handling the time zone correctly? Is there a better way to manage things when the user's time zone setting is different from the server's? Right now it's a mess...
>
> -David
>
>
> On Feb 23, 2010, at 10:03 PM, David E Jones wrote:
>
>>
>> What's strange is that this was working fine, even on MySQL, the last time I played with it. Unfortunately that was a bit of time ago so I don't have a good reference to narrow this down.
>>
>> I'll try some things on Derby and see if I can reproduce it, and with more detailed steps to do so.
>>
>> -David
>>
>>
>> On Feb 23, 2010, at 9:49 PM, Adrian Crum wrote:
>>
>>> I was unable to reproduce the problem in the Example component using Derby.
>>>
>>> -Adrian
>>>
>>> --- On Tue, 2/23/10, David E Jones <de...@me.com> wrote:
>>>
>>>> From: David E Jones <de...@me.com>
>>>> Subject: entity-one no longer converting types (probably a GenericEntity.setAllFields issue)
>>>> To: dev@ofbiz.apache.org
>>>> Date: Tuesday, February 23, 2010, 8:32 PM
>>>>
>>>> Has anyone made any changes GenericEntity.setAllFields
>>>> method or the code underneath it? It no longer works unless
>>>> the primary key consists only of String type fields.
>>>>
>>>> This is easy to reproduce, even in the Example Application,
>>>> by trying to work with ExampleFeatureAppl records, which
>>>> have a fromDate as part of the primary key.
>>>>
>>>> This warning is showing, and the underlying code does not
>>>> work (on MySQL at least):
>>>>
>>>>
>>>> [java] 2010-02-23 21:22:42,706
>>>> (http-0.0.0.0-8443-1) [
>>>> GenericEntity.java:422:WARN ]
>>>> [java] ---- exception report
>>>> ----------------------------------------------------------
>>>> [java] =-=-=-=-=-=-=-=-= Database
>>>> type warning GenericEntity.set =-=-=-=-=-=-=-=-= In entity
>>>> field [ProductFeatureAndAppl.fromDate] set the value passed
>>>> in [java.lang.String] is not compatible with the Java type
>>>> of the field [java.sql.Timestamp]
>>>> [java] Exception:
>>>> java.lang.Exception
>>>> [java] Message: Location of
>>>> database type warning
>>>> [java] ---- stack trace
>>>> ---------------------------------------------------------------
>>>> [java] java.lang.Exception:
>>>> Location of database type warning
>>>> [java]
>>>> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:422)
>>>> [java]
>>>> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:368)
>>>> [java]
>>>> org.ofbiz.entity.GenericEntity.setAllFields(GenericEntity.java:885)
>>>> [java]
>>>> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:105)
>>>> [java]
>>>> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:81)
>>>> [java]
>>>> org.ofbiz.widget.screen.ModelScreenAction$EntityOne.runAction(ModelScreenAction.java:523)
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
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.
On a side note, when using set with the from-field attribute it does not use a FlexibleStringExpander, it uses a FlexibleMapAccessor, which does return an object.
-David
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adrian Crum <ad...@hlmksw.com>.
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?
Both of you have identified a problem. I don't think they are mutually
exclusive.
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adam Heath <do...@brainfood.com>.
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.
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adrian Crum <ad...@hlmksw.com>.
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. ;-)
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adam Heath <do...@brainfood.com>.
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.
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
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.
-David
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adam Heath <do...@brainfood.com>.
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?
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
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.
-David
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adam Heath <do...@brainfood.com>.
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.
Re: Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by Adam Heath <do...@brainfood.com>.
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 "").
Time Zone Issues (was Re: entity-one no longer converting types
(probably a GenericEntity.setAllFields issue))
Posted by David E Jones <de...@me.com>.
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>
This also does not work, but should:
<entity-one entity-name="ProductFeatureAndAppl" value-field="productFeatureAndAppl" auto-field-map="true"/>
The problem turns out to not be with the data type, but with the time zone being treated differently in different cases.
I'll work on getting both of these to do the server-side time zone compensation the same as the first one.
I'm wondering though: how many more places are not handling the time zone correctly? Is there a better way to manage things when the user's time zone setting is different from the server's? Right now it's a mess...
-David
On Feb 23, 2010, at 10:03 PM, David E Jones wrote:
>
> What's strange is that this was working fine, even on MySQL, the last time I played with it. Unfortunately that was a bit of time ago so I don't have a good reference to narrow this down.
>
> I'll try some things on Derby and see if I can reproduce it, and with more detailed steps to do so.
>
> -David
>
>
> On Feb 23, 2010, at 9:49 PM, Adrian Crum wrote:
>
>> I was unable to reproduce the problem in the Example component using Derby.
>>
>> -Adrian
>>
>> --- On Tue, 2/23/10, David E Jones <de...@me.com> wrote:
>>
>>> From: David E Jones <de...@me.com>
>>> Subject: entity-one no longer converting types (probably a GenericEntity.setAllFields issue)
>>> To: dev@ofbiz.apache.org
>>> Date: Tuesday, February 23, 2010, 8:32 PM
>>>
>>> Has anyone made any changes GenericEntity.setAllFields
>>> method or the code underneath it? It no longer works unless
>>> the primary key consists only of String type fields.
>>>
>>> This is easy to reproduce, even in the Example Application,
>>> by trying to work with ExampleFeatureAppl records, which
>>> have a fromDate as part of the primary key.
>>>
>>> This warning is showing, and the underlying code does not
>>> work (on MySQL at least):
>>>
>>>
>>> [java] 2010-02-23 21:22:42,706
>>> (http-0.0.0.0-8443-1) [
>>> GenericEntity.java:422:WARN ]
>>> [java] ---- exception report
>>> ----------------------------------------------------------
>>> [java] =-=-=-=-=-=-=-=-= Database
>>> type warning GenericEntity.set =-=-=-=-=-=-=-=-= In entity
>>> field [ProductFeatureAndAppl.fromDate] set the value passed
>>> in [java.lang.String] is not compatible with the Java type
>>> of the field [java.sql.Timestamp]
>>> [java] Exception:
>>> java.lang.Exception
>>> [java] Message: Location of
>>> database type warning
>>> [java] ---- stack trace
>>> ---------------------------------------------------------------
>>> [java] java.lang.Exception:
>>> Location of database type warning
>>> [java]
>>> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:422)
>>> [java]
>>> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:368)
>>> [java]
>>> org.ofbiz.entity.GenericEntity.setAllFields(GenericEntity.java:885)
>>> [java]
>>> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:105)
>>> [java]
>>> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:81)
>>> [java]
>>> org.ofbiz.widget.screen.ModelScreenAction$EntityOne.runAction(ModelScreenAction.java:523)
>>>
>>> -David
>>>
>>>
>>>
>>
>>
>>
>
Re: entity-one no longer converting types (probably a
GenericEntity.setAllFields issue)
Posted by David E Jones <de...@me.com>.
What's strange is that this was working fine, even on MySQL, the last time I played with it. Unfortunately that was a bit of time ago so I don't have a good reference to narrow this down.
I'll try some things on Derby and see if I can reproduce it, and with more detailed steps to do so.
-David
On Feb 23, 2010, at 9:49 PM, Adrian Crum wrote:
> I was unable to reproduce the problem in the Example component using Derby.
>
> -Adrian
>
> --- On Tue, 2/23/10, David E Jones <de...@me.com> wrote:
>
>> From: David E Jones <de...@me.com>
>> Subject: entity-one no longer converting types (probably a GenericEntity.setAllFields issue)
>> To: dev@ofbiz.apache.org
>> Date: Tuesday, February 23, 2010, 8:32 PM
>>
>> Has anyone made any changes GenericEntity.setAllFields
>> method or the code underneath it? It no longer works unless
>> the primary key consists only of String type fields.
>>
>> This is easy to reproduce, even in the Example Application,
>> by trying to work with ExampleFeatureAppl records, which
>> have a fromDate as part of the primary key.
>>
>> This warning is showing, and the underlying code does not
>> work (on MySQL at least):
>>
>>
>> [java] 2010-02-23 21:22:42,706
>> (http-0.0.0.0-8443-1) [
>> GenericEntity.java:422:WARN ]
>> [java] ---- exception report
>> ----------------------------------------------------------
>> [java] =-=-=-=-=-=-=-=-= Database
>> type warning GenericEntity.set =-=-=-=-=-=-=-=-= In entity
>> field [ProductFeatureAndAppl.fromDate] set the value passed
>> in [java.lang.String] is not compatible with the Java type
>> of the field [java.sql.Timestamp]
>> [java] Exception:
>> java.lang.Exception
>> [java] Message: Location of
>> database type warning
>> [java] ---- stack trace
>> ---------------------------------------------------------------
>> [java] java.lang.Exception:
>> Location of database type warning
>> [java]
>> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:422)
>> [java]
>> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:368)
>> [java]
>> org.ofbiz.entity.GenericEntity.setAllFields(GenericEntity.java:885)
>> [java]
>> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:105)
>> [java]
>> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:81)
>> [java]
>> org.ofbiz.widget.screen.ModelScreenAction$EntityOne.runAction(ModelScreenAction.java:523)
>>
>> -David
>>
>>
>>
>
>
>
Re: entity-one no longer converting types (probably a GenericEntity.setAllFields issue)
Posted by Adrian Crum <ad...@yahoo.com>.
I was unable to reproduce the problem in the Example component using Derby.
-Adrian
--- On Tue, 2/23/10, David E Jones <de...@me.com> wrote:
> From: David E Jones <de...@me.com>
> Subject: entity-one no longer converting types (probably a GenericEntity.setAllFields issue)
> To: dev@ofbiz.apache.org
> Date: Tuesday, February 23, 2010, 8:32 PM
>
> Has anyone made any changes GenericEntity.setAllFields
> method or the code underneath it? It no longer works unless
> the primary key consists only of String type fields.
>
> This is easy to reproduce, even in the Example Application,
> by trying to work with ExampleFeatureAppl records, which
> have a fromDate as part of the primary key.
>
> This warning is showing, and the underlying code does not
> work (on MySQL at least):
>
>
> [java] 2010-02-23 21:22:42,706
> (http-0.0.0.0-8443-1) [
> GenericEntity.java:422:WARN ]
> [java] ---- exception report
> ----------------------------------------------------------
> [java] =-=-=-=-=-=-=-=-= Database
> type warning GenericEntity.set =-=-=-=-=-=-=-=-= In entity
> field [ProductFeatureAndAppl.fromDate] set the value passed
> in [java.lang.String] is not compatible with the Java type
> of the field [java.sql.Timestamp]
> [java] Exception:
> java.lang.Exception
> [java] Message: Location of
> database type warning
> [java] ---- stack trace
> ---------------------------------------------------------------
> [java] java.lang.Exception:
> Location of database type warning
> [java]
> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:422)
> [java]
> org.ofbiz.entity.GenericEntity.set(GenericEntity.java:368)
> [java]
> org.ofbiz.entity.GenericEntity.setAllFields(GenericEntity.java:885)
> [java]
> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:105)
> [java]
> org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:81)
> [java]
> org.ofbiz.widget.screen.ModelScreenAction$EntityOne.runAction(ModelScreenAction.java:523)
>
> -David
>
>
>