Hi Jacques

I really don't think it has anything to do with groovy, it is just
passing a simple string into the entity condition which is no more or
less than beanshell would have done.  I think it just seems that way
because we noticed the problem after the beanshell->groovy switch, the
change probably came from postgresql in some recent version.

I'll have a look at the double problem as soon as I get a chance.

Thanks
Scott

2008/10/13 Jacques Le Roux <[EMAIL PROTECTED]>:
> Hi Scott,
>
> No time to look into details tonight. Just to let you know that I considered
> this a Groovy issue because it seems that the same code used in Beanshell
> did not have this problem. Maybe it's no related to Groovy itself, but the
> way we interface it ?
>
> BTW we have the same kind of issue (not timestamp related though) at
> https://localhost:8443/facility/control/ViewFacilityInventoryItemsDetails
> There it's between  "double precision" and "character varying". I guess, the
> same kinf of fix may be applied as well
>
> Jacques
>
> From: "Scott Gray" <[EMAIL PROTECTED]>
>>
>> I've had a look into this and I can't see anything related to Groovy
>> that is making this necessary, it appears to be entirely a postgresql
>> issue.
>>
>> When executing a prepared statement postgresql seems to require that
>> the parameter list sql types match the column types.  So the problem
>> isn't that we are passing in a string but that we are setting the sql
>> type to character varying by using PreparedStatement.setString().
>>
>> Here's a patch that fixes the issue but I'm not really confident
>> enough to commit it, it would be great to get some comments from
>> people who know more about this kind of thing:
>>
>> Index: framework/entity/src/org/ofbiz/entity/jdbc/SQLProcessor.java
>> ===================================================================
>> --- framework/entity/src/org/ofbiz/entity/jdbc/SQLProcessor.java (revision
>> 703572)
>> +++ framework/entity/src/org/ofbiz/entity/jdbc/SQLProcessor.java (working
>> copy)
>> @@ -592,6 +592,22 @@
>>     *
>>     * @throws SQLException
>>     */
>> +    public void setValueTimestampString(String field) throws SQLException
>> {
>> +        if (field != null) {
>> +            _ps.setObject(_ind, field, Types.TIMESTAMP);
>> +        } else {
>> +            _ps.setNull(_ind, Types.TIMESTAMP);
>> +        }
>> +        _ind++;
>> +    }
>> +
>> +    /**
>> +     * Set the next binding variable of the currently active prepared
>> statement.
>> +     *
>> +     * @param field
>> +     *
>> +     * @throws SQLException
>> +     */
>>    public void setValue(java.sql.Time field) throws SQLException {
>>        if (field != null) {
>>            _ps.setTime(_ind, field);
>> Index: framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java
>> ===================================================================
>> --- framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java (revision
>> 703572)
>> +++ framework/entity/src/org/ofbiz/entity/jdbc/SqlJdbcUtil.java (working
>> copy)
>> @@ -731,6 +731,9 @@
>>                    fieldClassName = "byte[]";
>>                }
>>
>> +                if ("java.sql.Timestamp".equals(fieldType)) {
>> +                fieldClassName = fieldType;
>> +                }
>>                if (Debug.verboseOn()) Debug.logVerbose("type of
>> field " + entityName + "." + modelField.getName() +
>>                        " is " + fieldClassName + ", was expecting "
>> + mft.getJavaType() + "; this may " +
>>                        "indicate an error in the configuration or in
>> the class, and may result " +
>> @@ -749,7 +752,11 @@
>>                break;
>>
>>            case 2:
>> -                sqlP.setValue((java.sql.Timestamp) fieldValue);
>> +            if (fieldValue instanceof String) {
>> +            sqlP.setValueTimestampString((String) fieldValue);
>> +            } else {
>> +            sqlP.setValue((java.sql.Timestamp) fieldValue);
>> +            }
>>                break;
>>
>>            case 3:
>>
>> Regards
>> Scott
>>
>>
>> 2008/10/13 Jacques Le Roux <[EMAIL PROTECTED]>:
>>>
>>> Done in revision: 703816
>>> It was not possible for PackingSlip.groovy and
>>>  FindInventoryEventPlan.groovy. Because there the date string is build
>>> dynamically in the Groovy file
>>>
>>> Jacques
>>>
>>> From: "Jacques Le Roux" <[EMAIL PROTECTED]>
>>>>
>>>> Adrian,
>>>>
>>>> Yes good idea indeed, I will do that
>>>>
>>>> Jacques
>>>>
>>>> From: "Adrian Crum" <[EMAIL PROTECTED]>
>>>>>
>>>>> Jacques,
>>>>>
>>>>> Instead of modifying the groovy files, try specifying the data type in
>>>>> the screen widget.
>>>>>
>>>>> Example in ReportFinancialSummaryScreens.xml:
>>>>>
>>>>> <set field="fromDate" from-field="parameters.fromDate"
>>>>> type="Timestamp"/>
>>>>> <set field="thruDate" from-field="parameters.thruDate"
>>>>> type="Timestamp"/>
>>>>> <script
>>>>>
>>>>> location="component://accounting/webapp/accounting/WEB-INF/actions/reports/TransactionTotals.groovy"/>
>>>>>
>>>>> -Adrian
>>>
>>>
>>
>
>

Reply via email to