Использование верблюжьего компонента sql кажется хорошей вещью в проекте с использованием верблюда. Но я не вижу смысла в случаях, когда нужен динамический sql. Случай использования:
на переднем конце пользователь может
- выберите только тип записи и отправьте запрос на поиск, в данном случае это предложение: «из таблицы1, где col1 = значениеX1»
- также выберите диапазон дат для даты начала предложения, а затем, где предложение выглядит как "из таблицы1, где col1 = значениеX1 и dateCol между (...)"
- и т. Д. Для другого пользовательского интерфейса, если значения даны в общей сложности для 10 различных столбцов в различных комбинациях
Я пытался использовать динамический SQL, выяснил три варианта:
1. используя список получателей, чтобы маршрут выбирался во время выполнения, казалось, убил.
2. используя тело как sql и используя useMessageBodyForSql = true
3. используя пользовательский prepareStatementStrategy
Для 2 и 3 я не смог отправить имена параметров или указать заголовки или свойства, которые должны быть частью значений, которые будут использоваться в подготовленном операторе.
Для .2. должен был дать sql как:
выберите c1, c2 ... из t1, где x =? и у =?
, а затем список утилит java со значениями по порядку.
Итак, есть ли преимущество в использовании этого? Любая особенность компонента sql, которая делает его более удобным, чем непосредственное использование шаблона Spring JDBC, который он использует?