elwood.su

Обнаружил сегодня очередной косяк в Hibernate, когда делал NativeQuery для таблицы, в
которой имеется поле типа TEXT. Как известно, хибер по умолчанию не создает такие поля,
а создает VARCHAR(255) для строковых значений, и
тип TEXT я задал специально при создании Entity-бинов с использованием аннотации
@Column(columnDefinition = “text”). И вот теперь select через NativeQuery не работает,
потому что

MySQL5: No Dialect mapping for JDBC type: -1

Из обсуждений http://opensource.atlassian.com/projects/hibernate/browse/HHH-1483
выяснилось, что этот диалект почему-то не хочет поддерживать тип TEXT.

В результате выяснилось, что победить эту проблему можно тремя способами :
1. Отказаться от использования TEXT в пользу VARCHAR(65535) – но это не всегда возможно,
особенно если база уже работает, и при выполнении alter table часть данных будет обрезана.
2. Заюзать хибернейтовский метод addScalar при формировании запроса.
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querysql.html (16.1.1 Scalar queries)
К сожалению, этот метод также не является идеальным, поскольку при использовании
EJB3 (а я использую именно его) не представляется возможным лезть на уровень ниже и
кастить интерфейс Query к хибернейтовскому SQLQuery, тем самым завязываясь на текущей
хибернейтовской имплементации EJB3.
3. Пропатчить класс-диалект, подменив его своим или занаследовавшись от него и добавив
специальный кейс для типа TEXT. В данном случае все прошло великолепно, я закинул
класс

public class MySQL5InnoDBDialectPatched extends org.hibernate.dialect.MySQL5InnoDBDialect {
    public MySQL5InnoDBDialectPatched() {
        super();
        // register additional hibernate types for default use in scalar sqlquery type auto detection
        registerHibernateType(Types.LONGVARCHAR, org.hibernate.Hibernate.TEXT.getName());
    }
}

в свойства persistence.xml, и все заработало.
Единственное, что пришлось добавить в проект – compile-time-зависимости для сборки
ejb-джарника. В моем случае это был всего лишь 1 файл hibernate3.jar.

При использовании commons.fileupload возникла проблема : русский текст, вводимый в input’ы, приходил в непонятной кодировке. Пробовал повесить фильтр, в котором выставить request’у и response’у кодировку utf-8 принудительно, но не помогло. Пробовал установить accept-charset на форме, тоже не помогло.
Единственное найденное решение – у получаемых значений конвертить кодировку из iso-8859-1 в utf-8 :

String convertedString = new String (string.getBytes ("iso-8859-1"), "UTF-8");

Вроде работает. Надеюсь в будущем покопать глубже, а пока останется такой миникостыль.

Если у вас при импорте модуля (iml-файл) идея тупит (не подцепляются исходники, зависимости), не спешите нажимать Synchronize. Откройте iml-файл в текстовом редакторе и внимательно пройдитесь по его содержимому. Возможно, IDEA просто не нашла один из путей. В моем случае это был путь к части исходников, которые генерировались из WSDL в директорию build/src. На момент импорта модуля этих директорий не было (поскольку они создаются при билде модуля), и IDEA некорректно обработала эту ситуацию, проигнорировав прописанные в iml зависимости. После создания директорий build и build/src повторный импорт сработал на ура.
В такой ситуации нажатие Synchronize приведет к тому, что IDEA перезапишет iml-файл, по сути, с нуля. Соответственно, потом файл будет закоммичен вами в VCS. В результате это может обернуться головной болью для всех других разработчиков, имеющих дело с модулем.