Используя критерии api, у меня есть запрос, который делает что-то вроде:
CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<SourcePath> pathQuery = cb.createQuery(SourcePath.class);
Root<SourcePath> pathRoot = pathQuery.from(SourcePath.class);
pathQuery.where(cb.equal(cb.literal(0x00010002).as(String.class), (pathRoot.get(SourcePath_.path))));
TypedQuery<SourcePath> query = entityManager.createQuery(pathQuery);
query.getResultList();
Полученный SQL-запрос приведет к следующему:
select ...snip aliases... from SourcePath where cast(x'00010002', char(1)) = path;
(путь будет каким-то неприятным старым псевдонимом, но это не имеет значения).
Этот запрос неверен. В частности, cast: cast(x'00010002', char(1))
не является отличным как строка, как указано .as(String.class)
, вместо этого он должен быть либо cast(x'00010002', char)
, либо cast(x'00010002', char(N)
, где N
является достаточно большим числом.
Я выделил причину этого отказа бросания для MySqlDialect, предоставленного org.hibernate. В частности:
public String getCastTypeName(int code) {
if ( code==Types.INTEGER ) {
return "signed";
}
else if ( code==Types.VARCHAR ) {
return "char";
}
...snip...
}
Что дальше по цепочке интерпретируется как char
, которая зарегистрирована в диалоговом окне: registerColumnType( Types.CHAR, "char(1)" );
.
Наконец, на мой вопрос. Как я могу обойти это поведение? Я сообщаю об этом как об ошибке в Hibernate? Расширить ли диалоговое окно и исправить возвращаемый тип из getCastTypeName? Есть ли альтернатива .as
, которая будет соответствующим образом отбрасываться? Или я должен использовать строки везде, где я сейчас использую шестнадцатеричные значения, чтобы избежать касания крайних случаев реализации спящего режима?
Спасибо СПР