Hibernate-reactive: 通过 Vert.x 驱动程序而不是 JDBC 导出模式

这有点奇怪。 同时，我不希望有太多方法来配置相同的连接字符串。 将来，用户可能能够将 ORM 与 Rx 一起使用，并且可能只想在某些情况下使用 Rx API。 我们使用 ORM 用户已经熟悉的属性也很好。

啊对不起。 我刚刚意识到你不是在谈论属性名称。

大多数情况下，我想知道是否有一个用例想要使用
不同的配置参数。
我想如果本机反应式驱动程序有一些特定的
特性。

无论如何，我想我们必须具有与 ORM 相似的属性，但是
从名称中删除jdbc部分。
并决定如果只设置一种类型的属性会发生什么。

2020 年 5 月 1 日星期五下午 5:53 Andrew Guibert通知@ github.com
写道：

出于同样的原因，我认为我们不应该过度制作东西
方便/熟悉。 例如，现在我们支持配置 RX
一个 jdbc 协议 URL，方便/熟悉但技术上不是
正确，因为我们没有使用 JDBC。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ，
或取消订阅
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

无论如何，我想我们将不得不具有与 ORM 相似的属性，但从名称中删除了jdbc部分。

我认为我们应该坚持使用标准的 JDBC URL 格式，因为：

• 这是标准的
• 数据库供应商对其进行了详细记录
• 每个人都已经知道了
• 它可以更轻松地同时配置 Hibernate RX和普通 Hibernate 或普通 JDBC

@DavideD我可能没有正确描述 OP 中的问题，但是配置参数如何对模式 gen 起作用？

为了重申我对这个问题的意图，我建议可以在不需要涉及任何 JDBC 驱动程序或 jdbc-only 配置的情况下完成自动删除/创建表过程（如果 RX 碰巧重用相同的属性，不过没关系）

啊对不起。 我刚刚意识到你不是在谈论属性名称。

是的，明白了。 我的错。 我第一次读得太快了。

如果他们的应用程序仅使用 RX，那么要求用户添加/配置 JDBC 驱动程序似乎有点尴尬。

这里的这句话让我觉得你在谈论这样一个事实，即我们使用 ORM 中已经存在的 JDBC 配置的属性。 我们谈论它仍然很好，我现在不打算改变它们。

所以之前我认为通过 JDBC 进行模式导出是完全没问题的。 （什么是反应式模式导出？）

然而，在与@emmanuelbernard和@Sanne 的电话交谈中，我注意到这确实是 Quarkus 用户的潜在痛点。

当@aguibert试图警告我这

所以，无论如何，这确实是一个我们应该优先考虑的问题，尽管我怀疑它无法在初始发布时及时完成。

奇怪的想法 - 如果它很愚蠢，请原谅我，因为我真的不知道 - 但想知道我们是否可以将反应式驱动程序包装到 JDBC 兼容的适配器中，然后将其输入到模式生成代码中？

我想如果这样的工作只是促进了 schemagen 工具，那么它会是矫枉过正的，但也许还有更多用途？

@Sanne

那么这里有一个抽象，称为GenerationTarget 。 我们也许能够实现这一点，尽管我不是 100% 确定如何插入一个。

如果做不到这一点，我们可能可以做的一件事是要求模式导出工具导出SCRIPT ，然后将命令一个一个地发送到数据库。

我们也许能够实现这一点，尽管我不是 100% 确定如何插入一个。

问题是这些目标的列表似乎是硬编码的，没有任何明显的方法来添加新的。 但是对核心的一个小修复可能足以解决这个问题。

好的。 虽然这仍然不是首要任务，但我会尽可能推迟发布下一个 ORM，以便万一有人找到时间，我们可以在最后一刻加入更多补丁。

作为参考，请记住执行发布确实不需要我们很长时间：大约 20 分钟。 但是我们需要等待 Maven 中央同步以及所有这些才能实际使用 :(
这意味着我们需要在响应式发布之前发布大约 24 小时。

我会留出一些时间来尝试这个。 也许它超级简单。 我们会发现的。

也许它超级简单。 我们会发现的。

所以，确实，它相对简单，但它提出了一个我没有考虑过的问题：Hibernate Reactive 不再可以访问 JDBC 元数据，这确实有一些后果，但我不认为它们太糟糕。 幸运的是，Hibernate 是在 JDBC 元数据非常不可靠的时候编写的，并且并不真正依赖它。

我想没关系。

它还暴露了ForeignKeys中的一个错误，其中 Hibernate Reactive 实际上会使用 JDBC 连接从数据库中获取快照！ 我将为该问题打开一个单独的错误报告。

很好，谢谢！

Gavin 的修复被合并到 ORM 中； 架构创建现在应该是可行的。

我怀疑自动模式更新虽然有点复杂 - 我们是否同意这对第一次削减不那么重要？

Gavin 的修复被合并到 ORM 中； 架构创建现在应该是可行的。

谢谢。

我怀疑自动模式更新虽然有点复杂

哦，要困难

我们是否同意这对第一次削减不那么重要？

是的，在这个阶段我根本没有打算做这件事。 我也觉得没必要。

@Sanne多久我们才能发布带有该更改的 ORM 核心？

@gavinking我们可以计划在周一发布。 我想知道 - 如果可能需要更多的更改，也许最好推迟？
我们还在研究 Quarkus 需要的其他一些修复——所以虽然我们可以随时发布一个，但越晚修复越多。

@Sanne 不要紧，该评论是在我发现 #113 的严重性之前发表的。

@gavinking在某个时候，您能否在 Vertx-sql-client 上写一个问题，概述 Hibernate 需要哪些类型的 DB 元数据？ Vertx 客户端应该拥有比目前更好的元数据 API。

+1 为安德鲁！

我们主动为 Postgres 构建元数据获取 API
https://github.com/eclipse-vertx/vertx-sql-client/pull/513。 反馈将
当然可以帮助我们围绕此构建更好的通用 API。

2020 年 5 月 14 日星期四晚上 9:58 Andrew Guibert通知@ github.com
写道：

@gavinking https://github.com/gavinking在某个时候你可以写
在 Vertx-sql-client 上提出了一个问题，概述了 DB 元数据的种类
Hibernate 需要吗？ Vertx 客户端应该有更好的元数据 API
比现在的某一天。

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/hibernate/hibernate-reactive/issues/104#issuecomment-628654875 ，
或取消订阅
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

模式管理工具需要的是访问information_schema.tables ，我猜也是information_schema.key_column_usage 。

模式管理工具需要的是访问information_schema.tables ，我猜也是information_schema.key_column_usage 。

请注意，一种选择是通过查询information_schema直接获取该信息。 从历史上看，它只是 JDBC 元数据 API，以便从平台差异中抽象出来。

这个做完了！

它以一种对用户非常透明的方式完成：如果他们设置了 JDBC 驱动程序或连接池，那么 Hibernate ORM 将通过 JDBC 进行模式导出，但如果他们没有 JDBC 驱动程序，则模式导出通过Vert.x 驱动程序将启动。

棒极了！
非常感谢

它以一种对用户非常透明的方式完成：如果他们设置了 JDBC 驱动程序或连接池，那么 Hibernate ORM 将通过 JDBC 进行模式导出，但 _iff_ 他们没有 JDBC 驱动程序，然后通过模式导出Vert.x 驱动程序将启动。

只是好奇，为什么要先尝试使用 JDBC 方法？ 如果我们有能力在 vertx 上运行它，为什么不总是这样做呢？

如果仅仅因为设置了一些不相关的连接而触发了不同的行为，则用户可能会感到困惑。 另外 - 你怎么知道其他连接是否真的指向同一个数据库？

只是好奇，为什么要先尝试使用 JDBC 方法？ 如果我们有能力在 vertx 上运行它，为什么不总是这样做呢？

好吧，如果您有常规的 Hibernate，那么为什么不使用常规的 JDBC 驱动程序呢？ 反应式模式导出不是一件有意义的事情。 为了让这一切正常工作，我们必须在最后做一个非常讨厌的join() ，这让 Vert.x 感到非常沮丧。

你怎么知道其他连接是否真的指向同一个数据库？

因为它是相同的 JDBC URL？