Jdbi: 开发人员指南：v2 到 v3 迁移

迁移小项目的注意事项：

重命名的类（所以不像删除导入并让 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 在您在Tools -> Database -> User Patterns下配置 Parameter Pattern 后理解语法。

Query不再具有Map的默认类型，因此无法直接调用list() 。 在调用 $#$23$ mapToMap()之前调用list() 。

TransactionStatus不再存在。

TransactionConsumer.useTransaction()现在只需要Handle ，因此在 Jdbi 上使用useTransaction()方法时需要删除TransactionStatus Jdbi Handle 。

TransactionCallback.inTransaction()现在只需要Handle ，因此在 Jdbi 上使用inTransaction()方法时需要删除TransactionStatus Jdbi或Handle 。

CallbackFailedException不再存在。 各种功能接口，例如HandleConsumer 、 HandleCallback 、 TransactionalConsumer和TransactionalCallback ，现在可以抛出任何异常类型（但限制使用泛型以避免不必要的检查异常处理）。

默认情况下不再提供 SQL 对象支持。 它必须注册每个创建的Jdbi实例。

IntelliJ 的迁移重构有助于启动迁移。

感谢@electrum把它放在一起！ 这将是一个很大的帮助

回顾我的演示文稿的一些额外说明：

• 工件重命名为 org.jdbi:jdbi -> org。 jdbi:jdbi3 , :jdbi3-sqlobject, :jdbi3-guava 等
• 核心包更改：org.skife.jdbi.v2 -> org.jdbi.v3。 这意味着在您迁移时 v2 和 v3 可以在一个项目中共存
• 重命名：GetHandle -> SqlObject
• v3 参数和映射器工厂使用java.lang.reflect.Type ，而 v2 使用java.lang.Class 。 这意味着 v3 能够处理 v2 无法处理的复杂泛型类型签名。
• v3 参数和映射器工厂以及返回可选项的单方法功能接口。 v2 有单独的 accept() 和 build() 方法。
• v3 中的 SQL 对象类型只能是公共接口——不能是类。 方法返回类型同样必须是公共的。 这是由于 SQL 对象实现从 CGLIB 切换到仅支持接口的 java.lang.reflect.Proxy。
• 通过编译代码并启用-parameters标志，可以使 SQL 对象方法参数上的@Bind注释成为可选的。
• 按需 SQL 对象不能与返回 Iterables 的方法配合使用。 按需对象在每次方法调用后严格关闭句柄，并且不再像在 v2 中那样“开门”让您完成对可迭代的消费。 这排除了连接泄漏的主要来源。
• SQL 对象不再是可关闭的——它们要么是按需的，要么它们的生命周期与它们所附加的句柄的生命周期相关联。
• StatementLocator接口从核心中移除。 所有核心语句现在都希望收到实际的 SQL。 添加了一个类似的概念， SqlLocator ，但仅限于 SQL 对象领域。

另一个： StatementRewriter已被重构为TemplateEngine和SqlParser 。

添加到列表中非常重要的是选择的行为。 它来自这个：

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();

我希望 v3 的额外功能、灵活性和安全性不会以冗长为代价。

嗨@javajosh ，我们不认为那个特定的太糟糕了，因为我们试图阻止映射到Map对象。 如果不出意外，围绕键区分大小写的规则令人困惑。 是否有某些原因您必须发出Map而不是创建自己定义的类型？ 我个人总是会编写小的结果类（使用构造函数/字段/属性映射器和绑定器）并且总是避免使用Map 。 你有一些非常方便的用例吗？

嗨@stevenschlansker - 我是从“开发人员第一次体验”的角度来看的。 上面的代码取自你自己的 v2 教程，我认为它是极简主义的。 事实上，对于像 Groovy 这样的 JVM 托管语言，它内置了类似 javascript 的映射，您可能会更频繁地看到非类型化结果。

@javajosh你觉得https://github.com/jdbi/jdbi/pull/925怎么样？

@stevenschlansker你是说#928 吗？

@stevenschlansker绝对是一个进步！ 但它仍然比 v2 更冗长。 :) 这是在 maven 等中更冗长的补充。我只是不想看到 JDBI 走 JUnit 的道路，JUnit 努力让人们采用 v4，因为它有一些不错的功能，但远比复杂得多v3 和 v3 “足够好”。 我对“withHandle”语法有同样的感觉（尽管我理解你消除所有悬空句柄的本能）。

@javajosh如果您想要更大的控制权，您仍然可以使用Jdbi.open() ，尽管我们建议您在 try-with-resources 块中使用它以确保安全。

开始处理 v2 到 v3 迁移文档。

@javajosh回到返回List<Map<String,Object>>的方法ResultBearing.list() $ ：我不确定添加这是一个好主意，尤其是在发布周期的后期。

我很理解您对冗长的担忧，但这种冗长的目的是为了澄清开发人员的意图：

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

对读者来说比：

handle.createQuery(sql)
    .list()

这是一件微妙的事情，我不羡慕你必须选择的职位。 JDBI 是一个不错的库，我很高兴简单地记录了我对冗长的担忧； 在这种特定情况下添加便利方法是否有意义，我不确定并且倾向于相信您对我的判断，因为我没有认真参与该项目！ 感谢收听！

如果您想出一个具体的例子来说明用更短的名字会更好，或者展示我们如何改进它，请告诉我们😄