Finder for UserType is broken?

dyn · **Joined:** Wed Aug 27, 2003 7:53 am **Posts:** 27

While tracking down my own problem, I modified the Hibernate3 CompositeUserTypeTest adding the following finder code from line 45 right after persisting a Transaction entity:

Code:

Query q = s.createQuery("from Transaction tran where tran.value = :value");
q.setParameter("value", new MonetoryAmount( new BigDecimal(1.5), Currency.getInstance("USD") ) );
q.list();

I believe this code should correctly find the persisted object. Instead, it gives the following error:

Code:

JDBCExceptionReporter  - could not execute query [select transactio0_.id as id0_, transactio0_.description as descript2_0_, transactio0_.amount as amount0_, transactio0_.currency as currency0_ from Trnsctn transactio0_ where (transactio0_.amount, transactio0_.currency)=?]
java.sql.SQLException: Parameter index out of range (2 > number of parameters, which is 1).
   at com.mysql.jdbc.PreparedStatement.setInternal(PreparedStatement.java:2250)
   at com.mysql.jdbc.PreparedStatement.setString(PreparedStatement.java:2949)
   at org.hibernate.type.StringType.set(StringType.java:26)
   at org.hibernate.type.CurrencyType.set(CurrencyType.java:78)
   at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:85)
   at org.hibernate.test.cut.MonetoryAmountUserType.nullSafeSet(MonetoryAmountUserType.java:153)

Does this mean a bug, or signals a problem in the MonetaryAmount UserType example, or in my logic maybe?

(I could not write a single UserType or CompositeUserType either which could generate a correct SQL query while using them as query parameters, that's why I started to play with the hibernate testcase but it did not seem to work out either).

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

You're not specifying the type in the setParameter line. Try something like this:

Code:

Query q = s.createQuery("from Transaction tran where tran.value = :value");
q.setParameter("value",
               new MonetoryAmount( new BigDecimal(1.5),                                             
                                  Currency.getInstance("USD") ),
               Hibernate.custom(YourHibernateType.class) );
q.list();

dyn · **Joined:** Wed Aug 27, 2003 7:53 am **Posts:** 27

I don't because the type can be guessed and Hibernate does a fine job doing so. Explicitly specifying the type makes no difference, the exact same error is being thrown. It gonna be something else..

dyn · **Joined:** Wed Aug 27, 2003 7:53 am **Posts:** 27

Does it smell like a bug to you as well? I'll post it to JIRA then tomorrow.

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

Oops, forgot that I was looking into this. I have to admit that I've never used composite user types with HQL. Google didn't help. The only example in HIA even vaguely similar to your query explicitly uses the (implicit) fields:

Code:

Query q = s.createQuery("from Transaction tran where tran.value.value = :value and tran.value.currency = :currency");
q.setParameter("value", new BigDecimal(1.5))
 .setParameter("currency", Currency.getInstance("USD") ) );
q.list();

If setParameter(compositeUserObject) is supposed to expand to two fields (as the exception suggests) and your assemble and disassemble methods are working, then JIRA does seem to be the next place to go.

dyn · **Joined:** Wed Aug 27, 2003 7:53 am **Posts:** 27

When I first met the problem, I was not sure at all that my assemble/disassemble methods are working correctly. I assumed I plain don't realize something with UserTypes and my code does something incorrectly.

However, as I wrote in the first post, I added a similar finder method (and nothing else) to the CompositeUserTypeTest class which comes with the Hibernate3 distribution (hibernate-3.1/test/org/hibernate/test/cut/CompositeUserTypeTest.java) and it gives the exact same error with the usertype written by the hibernate team... I think we can safely assume that their test code is correct.

I'll drop this into JIRA. Thanks for your comments.

dyn · **Joined:** Wed Aug 27, 2003 7:53 am **Posts:** 27

For further reference, it's HHH-1465.