В someEntity.entityValue какой тип? Попробуй для начала убрать to_clob и указать явно jdbcType в #{}

Как конкретно пробовал? #{someEntity.entityValue,jdbcType=CLOB} так? Тут написано, что ClobTypeHandler должен вызываться, он вызывается?
И текст ошибки бы еще)

MyBatis вполне удобный, если много больших и сложных запросов

Если запросы большие, то держать их в коде ужасно неудобно/нечитабельно и это приводит к ошибкам. Чтобы запрос можно было удобно прочитать и отлаживать, его хочется вынести в отдельный файл. Если в один файл хочешь положить несколько запросов, то нужна структура для файла. Какие еще есть удобные структуры для хранения запросов? Можешь предложить структуру вместо xml или спрособ хранения этих запросов?
+ mybatis дает возможность маппить результат запроса сразу в нужный dto - в голом jdbc с этим ResultSet-ом будет много лишней возьни

Еще раз, есть проблема: большие sql запросы
В хибернейте:
1) Через hql их написать часто просто невозможно
2) Нативные запросы в java коде - это боль, от который мы хотим уйти (почему описано постом выше)
В jooq-е:
1) Большие запросы это просто нечитаемое нечто, которые невозможно отлаживать в sql редакторе

Какие еще варианты решения? От MyBatis-а никто не отказывался, он всегда занимал узкую нишу для особых случаев.
Проще это понятие относительное, кому-то изначально было тоже проще работать с jdbc, а не hibernate-ом. Учишь hibernate и он становится проще jdbc. Учишь mybatis и он становится проще jdbc. По сравнению с jdbc, mybatis сильно и упрощает и уменьшает размер кода

Тем, что его нельзя просто взять и запустить в sql тулзе. Да и сам этот запрос захламлен java кодом. Вначале запрос пишут, а потом вставляют его в код. С jooq-ом надо написать sql запрос, потом написать аналогичный java код. И делать так каждый раз при правках


Количество тем со смыслом "какой же spring/hibernate/javaee/java/... неудобное Г" больше в разы. Отсюда делаем выводы, что эти все проекты хуже?


Ну редактор скл это и есть какой-то скл тулз