Jdbi: Руководство разработчика: переход с версии 2 на версию 3

Примечания по переносу небольшого проекта:

Переименованные классы (так что не так просто, как удалить импорт и позволить IDE исправить это):

• DBI -> Jdbi
• IDBI -> Jdbi
• DBIException -> JdbiException

Конструкторы для Jdbi были заменены фабричным методом create() .

ResultSetMapper заменяется на RowMapper , а метод map больше не имеет индекса строки. В Jdbi 3 существует класс с именем ResultSetMapper , но он служит другой цели. @Mapper заменяется на @UseRowMapper . registerMapper() на Jdbi заменяется на registerRowMapper() .

@BindIn заменяется на @BindList и больше не требует StringTemplate.

При использовании шаблонов Jdbi по умолчанию угловые скобки не заключаются в кавычки, что означает, что IntelliJ понимает синтаксис после настройки шаблона параметров в меню Инструменты -> База данных -> Пользовательские шаблоны .

Query больше не имеет типа по умолчанию Map и, таким образом, list() не может вызываться из него напрямую. Позвоните mapToMap() перед вызовом list() .

TransactionStatus больше не существует.

TransactionConsumer.useTransaction() #$ теперь принимает только Handle , поэтому аргумент TransactionStatus необходимо удалить при использовании этого с методами useTransaction() на Jdbi или Handle .

TransactionCallback.inTransaction() #$ теперь принимает только Handle , поэтому аргумент TransactionStatus необходимо удалить при использовании этого с методами inTransaction() на Jdbi или Handle .

CallbackFailedException больше не существует. Различные функциональные интерфейсы, такие как HandleConsumer , HandleCallback , TransactionalConsumer и TransactionalCallback , теперь могут генерировать исключения любого типа (но ограничены использованием дженериков, чтобы избежать ненужных проверок). Обработка исключений).

Поддержка объектов SQL больше недоступна по умолчанию. Он должен быть зарегистрирован для каждого созданного экземпляра Jdbi .

IntelliJ Migrate Refactor помог начать миграцию.

Спасибо @electrum за это! Это будет большая помощь

Некоторые дополнительные примечания по результатам обзора моей презентации:

• Артефакты переименованы в org.jdbi:jdbi -> org. jdbi: jdbi3 , : jdbi3-sqlobject, : jdbi3-guava и т. д.
• Изменен основной пакет: org.skife.jdbi.v2 -> org.jdbi.v3. Это означает, что версии 2 и 3 могут сосуществовать в проекте во время миграции.
• Переименовано: GetHandle -> SqlObject.
• Аргумент v3 и фабрики картографов используют java.lang.reflect.Type , тогда как v2 использовали java.lang.Class . Это означает, что версия 3 способна обрабатывать сложные сигнатуры универсального типа, чего не могла сделать версия 2.
• v3 фабрики аргументов и преобразователей, а также функциональные интерфейсы с одним методом, которые возвращают необязательный. v2 имел отдельные методы accept() и build().
• Типы объектов SQL в версии 3 должны быть только общедоступными интерфейсами, а не классами. Типы возврата метода также должны быть общедоступными. Это связано с переключением реализации объекта SQL с CGLIB на java.lang.reflect.Proxy, который поддерживает только интерфейсы.
• Аннотации @Bind к параметрам метода объекта SQL можно сделать необязательными, скомпилировав код с включенным флагом -parameters .
• Объекты SQL по запросу плохо сочетаются с методами, которые возвращают Iterables. Объекты по запросу строго закрывают дескриптор после каждого вызова метода и больше не «держат дверь открытой», чтобы вы могли закончить использование итерируемого объекта, как это было в версии 2. Это исключает основной источник утечек соединения.
• Объекты SQL больше нельзя закрыть — они либо открываются по требованию, либо их жизненный цикл привязан к жизненному циклу дескриптора, к которому они были прикреплены.
• Интерфейс StatementLocator удален из ядра. Все основные операторы ожидают получения фактического SQL сейчас. Аналогичная концепция SqlLocator была добавлена, но только в области объектов SQL.

Еще один: StatementRewriter преобразован в TemplateEngine и SqlParser .

Очень важно добавить в список поведение select. Отсюда пошло:

List<Map<String, Object>> rs = h.select("select id, name from something");

К этому:

List<Map<String, Object>> rs = h.select("select id, name from something").mapToMap().list();

Я бы хотел, чтобы дополнительная мощность, гибкость и безопасность версии 3 не шли за счет многословия.

Привет, @javajosh , мы не считаем этот конкретный случай слишком плохим, потому что мы пытаемся воспрепятствовать сопоставлению с объектами Map . По крайней мере, правила чувствительности к регистру для ключей сбивают с толку. Есть ли какая-то причина, по которой вы должны испускать Map , а не создавать свой собственный определенный тип? Лично я всегда буду писать небольшие результирующие классы (используя конструкторы/поля/сопоставители свойств и связыватели) и всегда избегаю использования Map . У вас есть какой-то вариант использования, где это очень удобно?

Привет @stevenschlansker - я подхожу к этому с точки зрения «первого опыта разработчиков». Приведенный выше код взят из вашего собственного учебника по версии 2, который, на мой взгляд, превосходно минималистичен. И действительно, с языком, размещенным на JVM, таким как Groovy, который имеет встроенную карту, похожую на javascript, вы, вероятно, чаще будете видеть нетипизированный результат.

@javajosh , что вы думаете о https://github.com/jdbi/jdbi/pull/925 ?

@stevenschlansker Вы имели в виду # 928 ?

@stevenschlansker Определенно улучшение! Но это все еще более многословно, чем v2. :) Это в дополнение к большей многословности в maven и т. д. Я просто не хочу, чтобы JDBI пошел по пути JUnit, который изо всех сил пытался заставить людей принять v4, потому что у него были некоторые хорошие функции, но он был намного сложнее, чем v3 и v3 были «достаточно хорошими». У меня такое же чувство по поводу синтаксиса withHandle (хотя я понимаю ваше стремление избавиться от всех оборванных дескрипторов).

@javajosh У вас все еще есть Jdbi.open() , если вы хотите большего контроля, хотя мы рекомендуем вам использовать его внутри блока try-with-resources для безопасности.

Начало работы над документами по переходу с версии 2 на версию 3.

@javajosh Возвращаясь к методу ResultBearing.list() , который возвращает List<Map<String,Object>> : я не уверен, что добавление этого было хорошей идеей, особенно в конце цикла выпуска.

Я с пониманием отношусь к вашим опасениям по поводу многословия, но это многословие служит цели прояснения намерений разработчика:

handle.createQuery(sql)
    .mapToMap()
    .list()

читателю понятнее, чем:

handle.createQuery(sql)
    .list()

Это деликатная вещь, и я не завидую тому, что тебе приходится выбирать. JDBI — хорошая библиотека, и я рад, что просто выразил свои опасения по поводу многословия; имеет ли смысл добавлять метод удобства в этом конкретном случае, я не уверен и склонен доверять вашему суждению, а не моему, поскольку я серьезно не участвую в проекте! Спасибо за внимание!

Пожалуйста, дайте нам знать, если вы придумаете конкретный пример того, как лучше с более коротким именем, или демонстрацию того, как мы могли бы улучшить его 😄