Hibernate-reactive: Schemaexport über Vert.x-Treiber statt JDBC

Es ist ein bisschen seltsam. Gleichzeitig würde ich es vorziehen, nicht zu viele Möglichkeiten zu haben, dieselbe Verbindungszeichenfolge zu konfigurieren. In Zukunft wird ein Benutzer wahrscheinlich ORM mit Rx verwenden können und möchte möglicherweise nur in einigen Fällen die Rx-API verwenden. Schön ist auch, dass wir Eigenschaften verwenden, die einem ORM-Benutzer bereits bekannt sind.

Oh, tut mir leid. Mir ist gerade aufgefallen, dass Sie nicht über die Grundstücksnamen gesprochen haben.

Meistens frage ich mich, ob es einen Anwendungsfall gibt, den man verwenden möchte
verschiedene Konfigurationsparameter.
Ich denke, es könnte passieren, wenn der native reaktive Treiber einige Besonderheiten hat
Eigenschaften.

Wie auch immer, ich denke, wir müssen ähnliche Eigenschaften wie die von ORM haben, aber
wobei der jdbc Teil aus dem Namen entfernt wurde.
Und entscheiden Sie, was passiert, wenn nur ein Eigenschaftstyp festgelegt ist.

Am Fr, 1. Mai 2020 um 17:53 Uhr Andrew Guibert [email protected]
schrieb:

Aus dem gleichen Grund denke ich nicht, dass wir mit der Herstellung von Dingen zu weit gehen sollten
bequem/vertraut. Zum Beispiel unterstützen wir derzeit die Konfiguration von RX mit
eine jdbc-Protokoll-URL, die praktisch/vertraut ist, aber nicht technisch
richtig, da wir JDBC nicht verwenden.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

Wie auch immer, ich denke, wir müssen ähnliche Eigenschaften wie die von ORM haben, aber mit dem jdbc Teil aus dem Namen.

Ich denke, wir sollten beim Standard-JDBC-URL-Format bleiben, weil:

• es ist standard
• es ist von den Datenbankanbietern gut dokumentiert
• jeder kennt es schon
• es erleichtert die gleichzeitige Konfiguration von Hibernate RX und Plain Hibernate oder Plain JDBC

@DavideD Ich habe das Problem im OP möglicherweise nicht richtig beschrieben, aber wie kommen Konfigurationsparameter für die

Um die Absicht zu wiederholen, die ich mit diesem Problem hatte, schlage ich vor, dass die automatischen Prozeduren zum Löschen/Erstellen von Tabellen durchgeführt werden können, ohne dass JDBC-Treiber oder nur jdbc-Konfigurationen erforderlich sind (wenn RX zufällig dieselben Eigenschaften wiederverwendet) , das ist aber in Ordnung)

Oh, tut mir leid. Mir ist gerade aufgefallen, dass Sie nicht über die Grundstücksnamen gesprochen haben.

Ja, habs verstanden. Mein Fehler. Ich habe es beim ersten Mal zu schnell gelesen.

Es scheint etwas umständlich zu verlangen, dass Benutzer einen JDBC-Treiber hinzufügen/konfigurieren, wenn ihre App nur RX verwendet.

Dieser Satz hier ließ mich glauben, dass Sie über die Tatsache sprechen, dass wir die Eigenschaften für die JDBC-Konfiguration verwenden, die bereits in ORM vorhanden sind. Es ist immer noch schön, dass wir darüber gesprochen haben und ich habe vorerst nicht vor, sie zu ändern.

Also habe ich vorher argumentiert, dass der Schemaexport über JDBC völlig in Ordnung ist. (Was ist ein reaktiver Schemaexport?)

Im Telefongespräch mit @emmanuelbernard und @Sanne ist mir jedoch aufgefallen , dass dies tatsächlich ein potenzieller Schmerzpunkt für Quarkus-Benutzer ist.

Ich hätte @aguibert mehr Aufmerksamkeit

Dies ist in der Tat ein Thema, das wir priorisieren sollten, obwohl ich vermute, dass es nicht rechtzeitig für die erste Veröffentlichung erledigt werden kann.

seltsame Idee - verzeihen Sie mir, wenn es albern ist, da ich es nicht wirklich weiß - aber fragen Sie sich, ob wir den reaktiven Treiber in einen JDBC-kompatiblen Adapter packen und ihn dann in den Schema-Gencode einspeisen könnten?

Ich denke, solche Arbeit wäre übertrieben, wenn sie nur die Schema-Tools erleichtern würde, aber vielleicht gibt es mehr Verwendungsmöglichkeiten?

@Sanne

Nun, es gibt hier eine Abstraktion namens GenerationTarget . Wir können das vielleicht implementieren, obwohl ich nicht 100% sicher bin, wie man einen anschließt.

Andernfalls können wir möglicherweise das Schemaexporttool bitten, ein SCRIPT zu exportieren und dann die Befehle einzeln an die DB zu senden.

Wir können das vielleicht implementieren, obwohl ich nicht 100% sicher bin, wie man einen anschließt.

Das Problem ist, dass die Liste dieser Ziele fest codiert zu sein scheint, ohne dass es offensichtlich eine Möglichkeit gibt, ein neues hinzuzufügen. Aber eine kleine Korrektur des Kerns könnte ausreichen, um das zu lösen.

Okay. Obwohl dies immer noch nicht die oberste Priorität ist, werde ich die Veröffentlichung des nächsten ORM so weit wie möglich verschieben. Falls also jemand die Zeit findet, können wir noch ein paar Last-Minute-Patches hinzufügen.

Denken Sie als Referenz daran, dass wir wirklich nicht lange brauchen, um die Veröffentlichung durchzuführen: etwa 20 Minuten. Aber dann müssen wir auf die zentrale Synchronisierung von Maven und all das warten, bevor sie tatsächlich verwendet werden kann :(
Das bedeutet, dass wir etwa 24 Stunden veröffentlichen müssen, bevor eine reaktive Veröffentlichung möglich ist.

Ich werde mir etwas Zeit nehmen, um dies zu versuchen. Vielleicht ist es supereinfach. Wir werden es rausfinden.

Vielleicht ist es supereinfach. Wir werden es rausfinden.

Es war in der Tat relativ einfach, aber es warf ein Problem auf, das ich nicht bedacht hatte: Hibernate Reactive hat keinen Zugriff mehr auf JDBC-Metadaten, was einige Konsequenzen hat, aber ich denke nicht, dass sie allzu schrecklich sind. Glücklicherweise wurde Hibernate geschrieben, als JDBC-Metadaten sehr unzuverlässig waren, und hängt nicht wirklich davon ab.

Ich denke, das ist in Ordnung.

Außerdem wurde ein Fehler in ForeignKeys aufgedeckt,

Super, danke!

Gavins Fix wurde in ORM zusammengeführt; Die Schemaerstellung sollte jetzt machbar sein.

Ich vermute jedoch, dass die automatische Schemaaktualisierung etwas komplizierter ist - können wir uns einigen, dass dies für den ersten Schnitt weniger wichtig ist?

Gavins Fix wurde in ORM zusammengeführt; Die Schemaerstellung sollte jetzt machbar sein.

Vielen Dank.

Ich vermute jedoch, dass die automatische Schemaaktualisierung etwas komplizierter ist

Oh, viel schwieriger, da die aktuelle Implementierung vollständig auf JDBC-Metadaten, IIRC, basiert.

Können wir uns einigen, dass das für den ersten Schnitt weniger wichtig ist?

Ja, ich habe überhaupt nicht die Absicht, daran zu arbeiten. Ich glaube auch nicht, dass es nötig ist.

@Sanne, wie lange

@gavinking können wir eine Veröffentlichung am Montag planen. Ich frage mich jedoch - wenn möglicherweise weitere Änderungen erforderlich sind, ist es vielleicht am besten, sie aufzuschieben?
Wir arbeiten auch an einigen anderen Fixes, die Quarkus braucht - wir können also zwar einen veröffentlichen, wann immer wir wollen, aber je später, desto mehr Fixes.

@Sanne Kein Halt, dieser Kommentar wurde gemacht, bevor ich die Ernsthaftigkeit von Nr. 113 entdeckt habe.

@gavinking könnten Sie irgendwann ein Problem mit dem Vertx-sql-client schreiben, in dem beschrieben wird, welche Arten von DB-Metadaten von Hibernate benötigt werden? Der Vertx-Client sollte über eine bessere Metadaten-API verfügen, als er es derzeit eines Tages tut.

+1 für Andreas!

Wir haben eine Initiative zum Aufbau einer API zum Abrufen von Metadaten für Postgres in
https://github.com/eclipse-vertx/vertx-sql-client/pull/513. Rückmeldungen werden
helfen uns sicherlich dabei, eine bessere generische API zu erstellen.

Am Do, 14. Mai 2020 um 21:58 Uhr Andrew Guibert [email protected]
schrieb:

@gavinking https://github.com/gavinking könntest du irgendwann schreiben
ein Problem auf dem Vertx-sql-client auf, in dem beschrieben wird, welche Arten von DB-Metadaten sind
benötigt von Hibernate? Der Vertx-Client sollte eine bessere Metadaten-API haben
als es derzeit eines Tages tut.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/hibernate/hibernate-reactive/issues/104#issuecomment-628654875 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

Was die Schemaverwaltungstools benötigen, ist Zugriff auf die Informationen in information_schema.tables und ich denke auch information_schema.key_column_usage .

Was die Schemaverwaltungstools benötigen, ist Zugriff auf die Informationen in information_schema.tables und ich denke auch information_schema.key_column_usage .

Beachten Sie, dass eine Möglichkeit darin besteht, diese Informationen direkt abzurufen, indem Sie information_schema abfragen. Historisch gesehen ist es nur die JDBC-Metadaten-API dafür, um von Plattformunterschieden abzustrahieren.

Das ist fertig!

Und das auf eine für den Benutzer ziemlich transparente Weise: Wenn ein JDBC-Treiber oder ein Verbindungspool eingerichtet ist, führt Hibernate ORM den Schemaexport über JDBC durch, aber wenn er keinen JDBC-Treiber hat, dann der Schemaexport über der Vert.x-Treiber wird aktiviert.

Das ist toll!
Danke vielmals

Und das auf eine für den Benutzer ziemlich transparente Weise: Wenn sie einen JDBC-Treiber oder einen Verbindungspool eingerichtet haben, führt Hibernate ORM den Schemaexport über JDBC durch, aber _iff_ sie haben keinen JDBC-Treiber, dann den Schemaexport über der Vert.x-Treiber wird aktiviert.

nur neugierig, warum sollte es zuerst versuchen, den JDBC-Ansatz zu verwenden? Wenn wir die Möglichkeit haben, es über Vertx auszuführen, warum nicht immer?

Es kann für Benutzer verwirrend sein, wenn verschiedene Verhaltensweisen ausgelöst werden, nur weil eine nicht verwandte Verbindung eingerichtet wird. Außerdem - woher wissen Sie, ob diese andere Verbindung wirklich auf dieselbe DB zeigt?

nur neugierig, warum sollte es zuerst versuchen, den JDBC-Ansatz zu verwenden? Wenn wir die Möglichkeit haben, es über Vertx auszuführen, warum nicht immer?

Nun, wenn Sie einen regulären Hibernate-Modus haben, der mit einem regulären JDBC-Treiber eingerichtet ist, warum verwenden Sie ihn nicht? Der reaktive Schemaexport ist keine sinnvolle Sache. Damit das überhaupt funktioniert, müssen wir am Ende ein total fieses join() , was Vert.x ziemlich ärgerlich findet.

woher wissen Sie, ob diese andere Verbindung wirklich auf dieselbe DB zeigt?

Weil es dieselbe JDBC-URL ist?