CODEWITHSUNDEEP
javamysqlhibernateormjdbc
jimbokun
jimbokun

Reputation: 133

No mapping for LONGVARCHAR in Hibernate 3.2

I am running Hibernate 3.2.0 with MySQL 5.1. After updating the group_concat_max_len in MySQL (because of a group_concat query that was exceeding the default value), I got the following exception when executing a SQLQuery with a group_concat clause:

"No Dialect mapping for JDBC type: -1"

-1 is the java.sql.Types value for LONGVARCHAR. Evidently, increasing the group_concat_max_len value causes calls to group_concat to return a LONGVARCHAR value. This appears to be an instance of this bug:

http://opensource.atlassian.com/projects/hibernate/browse/HHH-3892

I guess there is a fix for this issue in Hibernate 3.5, but that is still a development version, so I am hesitant to put it into production, and don't know if it would cause issues for other parts of my code base. I could also just use JDBC queries, but then I have to replace every instance of a SQLQuery with a group_concat clause.

Any other suggestions?

Upvotes: 4

Views: 2765

Answers (2)

jimbokun
jimbokun

Reputation: 133

Pascal's answer sounds very good, but I took a shortcut, for now.

Calling addScalar for every query return value also alleviates this problem. As it turns out, there were not very many places in my code with a group_concat but no explicit calls to addScalar. Adding these makes the issue go away. (Note that you must have a call to addScalar for every return value, not just those coming from a group_concat.)

Upvotes: 1

Pascal Thivent
Pascal Thivent

Reputation: 570365

Yes, two suggestions. Either:

  1. Patch Hibernate 3.2.0 with the changes of HHH-3892 i.e. get Hibernate sources, apply the patches for r16501, r16823 and r17332) and build Hibernate yourself.

  2. Or use a custom dialect as suggested in HHH-1483:

    public class MySQL5Dialect extends org.hibernate.dialect.MySQL5Dialect {
    public MySQL5Dialect() {
        super();
        // register additional hibernate types for default use in scalar sqlquery type auto detection
        // http://opensource.atlassian.com/projects/hibernate/browse/HHH-1483
        registerHibernateType(Types.LONGVARCHAR, Hibernate.TEXT.getName());
    }    
}

Option #2 is easy to implement and to test (I didn't) while option #1 is "cleaner" but require (a bit) more work. Personally, I'd choose option #1 because that's what you will get with 3.5 and thus guarantees a seamless upgrade.

Upvotes: 3

Related Questions