[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2851) ParameterTranslationsImpl fails to correctly determine parameter type

[Marcus Smith (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31555#action_31555 ] 

Marcus Smith commented on HHH-2851:
-----------------------------------

Recently had this with a namedQuery where the parameter was being passed in as null  to the following snippet

( :inDaysToDisplay IS NULL OR
(td.closed_date + :inDaysToDisplay)>=TO_DATE (:refDate, 'yyyy-mm-dd hh24:mi:ss'))

Resulting in the Oracle "ORA-00932: inconsistent datatypes: expected NUMBER got BINARY" exception.

The work around is to test for null before the parameter is set in the map and to pass in an empty string if it is null. Oracle treats an empty string as null.

i.e.  param.put("inDaysToDisplay", (daysToDisplay==null ? "" : daysToDisplay));

Works perfectly!.

> ParameterTranslationsImpl fails to correctly determine parameter type
> ---------------------------------------------------------------------
>
>                 Key: HHH-2851
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2851
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: query-hql
>    Affects Versions: 3.2.5
>            Reporter: Alex Savitsky
>            Priority: Minor
>         Attachments: HibernateTestCase.zip, patch.txt
>
>
> For the conditions in the form "(:param IS NULL OR alias.someField = :param)", the HQL parses would not correctly determine the type of param, unless the conditions are swapped like "(alias.someField = :param OR :param IS NULL)". The reason is that NamedParamTempHolder classes are created for all parameter entries, in the order they appear in the query. The first occurrence (:param IS NULL) would have its expectedType set to null, and the second occurrence would use the param holder created by the first occurrence, without checking whether it can improve it in any way (which it can - the expectedType for second occurrence is correctly determined to be Long).
> Proposed fix would be to check for this particular condition, enhancing paramHolder if possible, with new information:
> old code:
> 				if ( paramHolder == null ) {
> 					paramHolder = new NamedParamTempHolder();
> 					paramHolder.name = namedSpec.getName();
> 					paramHolder.type = namedSpec.getExpectedType();
> 					namedParameterMap.put( namedSpec.getName(), paramHolder );
> 				}
> new code:
> 				if ( paramHolder == null ) {
> 					paramHolder = new NamedParamTempHolder();
> 					paramHolder.name = namedSpec.getName();
> 					paramHolder.type = namedSpec.getExpectedType();
> 					namedParameterMap.put( namedSpec.getName(), paramHolder );
> +				} else if (paramHolder.getExpectedType() == null && namedSpec.getExpectedType() != null) {
> +					paramHolder.type = namedSpec.getExpectedType();
> 				}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira