Hibernate-reactive: JDBCの代わりにVert.xドライバーを介したスキーマのエクスポート

少し変です。 同時に、同じ接続文字列を構成する方法が多すぎないようにしたいと思います。 将来的には、ユーザーはRxでORMを使用できるようになる可能性があり、場合によってはRxAPIを使用したい場合があります。 ORMユーザーにすでに馴染みのあるプロパティを使用するのも良いことです。

すみません。 あなたが物件名について話していなかったことに気づきました。

ほとんどの場合、使用したいユースケースがあるかどうか疑問に思います
さまざまな構成パラメーター。
ネイティブのリアクティブドライバーに特定の機能がある場合に発生する可能性があると思います
プロパティ。

とにかく、ORMのものと同様のプロパティが必要になると思いますが
jdbc部分が名前から削除されています。
そして、1つのタイプのプロパティのみが設定されている場合に何が起こるかを決定します。

金曜、午前5時53分PMアンドリューGuibertで2020年5月1日には[email protected]
書きました：

同じように、物を作ることで行き過ぎてはいけないと思います
便利/なじみのある。 たとえば、現在、RXの構成をサポートしています。
jdbcプロトコルのURL。便利で馴染みがありますが、技術的にはそうではありません。
JDBCを使用していないので、正しいです。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
。

とにかく、ORMと同様のプロパティが必要になると思いますが、名前からjdbc部分が削除されています。

次の理由から、標準のJDBCURL形式を使用する必要があると思います。

• それは標準です
• データベースベンダーによって十分に文書化されています
• 誰もがすでにそれを知っています
• HibernateRXとプレーンHibernateまたはプレーンJDBCを同時に構成するのが簡単になります

@DavideD OPで問題を適切に説明していない可能性がありますが、スキーマ生成の構成パラメーターはどのように機能しますか？

この問題で私が持っていた意図を言い換えると、JDBCドライバーやjdbcのみの構成（RXが同じプロパティを再利用する場合）を必要とせずに、テーブルの自動削除/作成手順を実行できることをお勧めします。 、それでも問題ありません）

すみません。 あなたが物件名について話していなかったことに気づきました。

ええ、わかりました。 私の悪い。 初めて読んだのが速すぎた。

アプリがRXのみを使用している場合、ユーザーにJDBCドライバーの追加/構成を要求するのは少し厄介なようです。

ここでのこの文は、ORMにすでに存在するJDBC構成のプロパティを使用しているという事実について話していると思いました。 それについて話し合ったのは今でもいいことで、今のところ変更する予定はありません。

そのため、以前は、JDBCを介してスキーマのエクスポートを行うことはまったく問題ないと主張していました。 （リアクティブスキーマエクスポートとは何ですか？）

しかし、@emmanuelbernardと@Sanneとの電話での会話で、実際に実際にQuarkusユーザーのための潜在的な痛みのポイントであることを私の注意に来ています。

@aguibertがこれについて私に警告しようとしたとき、私はもっと注意を払うべき

ですから、とにかく、これは確かに私たちが優先すべき問題ですが、最初のリリースに間に合うようにそれを行うことはできないと思います。

奇妙なアイデア-私が本当に知らないのでばかげているなら許してください-しかし、リアクティブドライバーをJDBC互換アダプターにラップして、それをスキーマ生成コードにフィードできるかどうか疑問に思っていますか？

スキーマゲンツールを容易にするだけなら、そのような作業はやり過ぎだと思いますが、おそらくもっと多くの用途がありますか？

@Sanne

ここにはGenerationTargetと呼ばれる抽象化があります。 それを実装できるかもしれませんが、プラグインする方法は100％正確にはわかりません。

それができない場合、私たちができるかもしれないことの1つは、スキーマエクスポートツールにSCRIPTをエクスポートするように依頼し、コマンドを1つずつDBに送信することです。

それを実装できるかもしれませんが、プラグインする方法は100％正確にはわかりません。

問題は、これらのターゲットのリストがハードコーディングされているように見え、新しいターゲットを追加する明確な方法がないことです。 しかし、コアへの小さな修正でそれを解決できるかもしれません。

Ok。 これはまだ最優先事項ではありませんが、次のORMのリリースは可能な限り延期するので、誰かが時間を見つけた場合に備えて、最後の最後のパッチを追加することができます。

参考までに、リリースの実行には実際には時間がかからないことを覚えておいてください。約20分です。 しかし、実際に使用できるようになる前に、Mavenの中央同期などを待つ必要があります:(
これは、リアクティブリリースが可能になる約24時間前にリリースする必要があることを意味します。

これを試すために少し時間を取っておきます。 おそらくそれは超簡単です。 調べます。

おそらくそれは超簡単です。 調べます。

したがって、実際、それは比較的簡単でしたが、私が考えていなかった問題が発生しました。HibernateReactiveはJDBCメタデータにアクセスできなくなり、いくつかの結果が生じますが、それほどひどいとは思いません。 幸い、Hibernateは、JDBCメタデータの信頼性が非常に低く、実際には依存していないときに作成されました。

大丈夫だと思います。

また、Hibernate Reactiveが実際にJDBC接続を使用してデータベースからスナップショットを取得する、 ForeignKeysバグを公開しました。 その問題について別のバグレポートを開きます。

素晴らしいです、ありがとう！

Gavinの修正はORMにマージされました。 スキーマの作成はこれで実行可能になるはずです。

自動化されたスキーマ更新はかなり複雑だと思いますが、最初のカットではそれほど重要ではないことに同意できますか？

Gavinの修正はORMにマージされました。 スキーマの作成はこれで実行可能になるはずです。

ありがとう。

自動化されたスキーマ更新はかなり複雑だと思いますが

現在の実装は完全にJDBCメタデータ、IIRCに基づいているため、ああ、はるかに困難です。

それが最初のカットにとってそれほど重要ではないことに同意できますか？

ええ、私はこの段階でそれに取り組むつもりは全くありません。 また、それが必要だとは思いません。

@Sanneは、その変更が加えられたORMコアのリリースを取得するまでどのくらい

@gavinking月曜日にリリースを計画できます。 でも、もっと変更が必要な場合は、延期するのが最善かもしれません。
Quarkusが必要とする他のいくつかの修正にも取り組んでいます。そのため、いつでも1つをリリースできますが、後で修正が増えます。

@Sanneしっかりとは言えません、そのコメントは私が＃113の深刻さを発見する前に行われました。

@gavinkingある時点で、Vertx-sql-clientに、Hibernateに必要なDBメタデータの種類の概要を説明する問題を記述できますか？ Vertxクライアントには、現在よりも優れたメタデータAPIが必要です。

アンドリューの+1！

Postgres用のメタデータフェッチAPIを構築するイニシアチブがあります
https://github.com/eclipse-vertx/vertx-sql-client/pull/513。 フィードバックは
確かに、これを中心に、より優れた汎用APIを構築するのに役立ちます。

21:58アンドリューGuibertの木、2020年5月14日には[email protected]
書きました：

@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も推測します。

1つのオプションは、 information_schemaクエリしてその情報を直接取得することです。 歴史的には、プラットフォームの違いから抽象化するために、そのためのJDBCメタデータAPIだけです。

これで完了です。

そして、それはユーザーに対してかなり透過的な方法で行われます。JDBCドライバーまたは接続プールが設定されている場合、Hibernate ORMはJDBCを介してスキーマのエクスポートを行いますが、JDBCドライバーがない場合は、スキーマをエクスポートします。 Vert.xドライバーが起動します。

すごい！
どうもありがとう

そして、それはユーザーに対してかなり透過的な方法で行われます。JDBCドライバーまたは接続プールが設定されている場合、Hibernate ORMはJDBCを介してスキーマのエクスポートを行いますが、JDBCドライバーがない場合は、スキーマをエクスポートします。 Vert.xドライバーが起動します。

好奇心が強いのですが、なぜ最初にJDBCアプローチを使用する必要があるのでしょうか。 vertx上で実行する機能がある場合は、常に実行してみませんか？

無関係な接続がセットアップされているという理由だけでさまざまな動作がトリガーされると、ユーザーが混乱する可能性があります。 また、他の接続が実際に同じDBを指しているかどうかをどのようにして知ることができますか？

好奇心が強いのですが、なぜ最初にJDBCアプローチを使用する必要があるのでしょうか。 vertx上で実行する機能がある場合は、常に実行してみませんか？

通常のHibernateを通常のJDBCドライバーでセットアップしている場合は、それを使用しないのはなぜですか？ リアクティブスキーマエクスポートは意味のあるものではありません。 これを機能させるには、最後に完全に厄介なjoin()を実行する必要がありますが、Vert.xはこれを非常に不快に感じています。

他の接続が本当に同じDBを指しているかどうかをどうやって知るのですか？

同じJDBCURLですか？