Hibernate-reactive: exportation de schéma via le pilote Vert.x au lieu de JDBC

Créé le 1 mai 2020  ·  28Commentaires  ·  Source: hibernate/hibernate-reactive

Actuellement, le RxPersistenceProvider n'a pas de support de schéma, ce qui signifie que des choses comme la création automatique de table doivent être effectuées par JDBC.

Il semble un peu gênant d'exiger des utilisateurs qu'ils ajoutent/configurent un pilote JDBC si leur application utilise uniquement RX. En théorie, nous devrions pouvoir faire la même génération de schéma en utilisant RxConnection au lieu de JDBC Connection.

problem

Tous les 28 commentaires

C'est un peu bizarre. En même temps, je préférerais ne pas avoir trop de façons de configurer la même chaîne de connexion. À l'avenir, un utilisateur pourra probablement utiliser ORM avec Rx et il pourrait vouloir utiliser l'API Rx uniquement dans certains cas. C'est aussi bien que nous utilisions des propriétés qui sont déjà familières à un utilisateur ORM.

Ah désolé. Je viens de me rendre compte que vous ne parliez pas des noms des propriétés.

Surtout, je me demande s'il y a un cas d'utilisation où l'on voudrait utiliser
différents paramètres de configuration.
Je suppose que cela pourrait arriver si le pilote réactif natif a des
Propriétés.

Quoi qu'il en soit, je suppose que nous devrons avoir des propriétés similaires à celles de l'ORM mais
avec la partie jdbc supprimée du nom.
Et décidez ce qui se passe si un seul type de propriétés est défini.

Le vendredi 1er mai 2020 à 17h53 Andrew Guibert [email protected]
a écrit:

De la même manière, je ne pense pas que nous devrions aller trop loin pour faire des choses
pratique/familier. Par exemple, nous prenons actuellement en charge la configuration de RX avec
une URL de protocole jdbc, qui est pratique/familière mais pas techniquement
correct puisque nous n'utilisons pas JDBC.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

Quoi qu'il en soit, je suppose que nous devrons avoir des propriétés similaires à celles de l'ORM mais avec la partie jdbc supprimée du nom.

Je pense que nous devrions nous en tenir au format d'URL JDBC standard car :

  • c'est la norme
  • il est bien documenté par les fournisseurs de bases de données
  • tout le monde le sait déjà
  • cela facilite la configuration simultanée de Hibernate RX et plain Hibernate ou plain JDBC

@DavideD Je n'ai peut-être pas correctement décrit le problème dans l'OP, mais comment les paramètres de configuration entrent-ils en jeu pour la génération de schéma?

Pour réaffirmer l'intention que j'avais avec ce problème, je suggère que les procédures automatiques de suppression/création de table puissent être effectuées sans avoir besoin d'impliquer de pilotes JDBC ou de configuration jdbc uniquement (si RX réutilise les mêmes propriétés , c'est bien quand même)

Ah désolé. Je viens de me rendre compte que vous ne parliez pas des noms des propriétés.

Ouais, j'ai compris. Ma faute. Je l'ai lu trop vite la première fois.

Il semble un peu gênant d'exiger des utilisateurs qu'ils ajoutent/configurent un pilote JDBC si leur application utilise uniquement RX.

Cette phrase ici m'a fait penser que vous parliez du fait que nous utilisons les propriétés de la configuration JDBC qui existent déjà dans ORM. C'est quand même bien qu'on en ait parlé et je ne compte pas les changer pour l'instant.

Donc, auparavant, je disais que l'exportation de schéma sur JDBC était parfaitement acceptable. (Qu'est-ce qu'une exportation de schéma réactive ?)

Cependant, lors d'une conversation téléphonique avec @emmanuelbernard et @Sanne , il a été porté à mon attention qu'il s'agit en fait d'un problème potentiel pour les utilisateurs de Quarkus.

J'aurais dû faire plus attention à @aguibert quand il a essayé de m'avertir à ce sujet.

Donc, de toute façon, c'est en effet un problème que nous devrions prioriser, même si je soupçonne que cela ne peut pas être fait à temps pour la version initiale.

idée étrange - pardonnez-moi si c'est idiot car je ne sais pas vraiment - mais vous vous demandez si nous pourrions envelopper le pilote réactif dans un adaptateur compatible JDBC, puis l'insérer dans le code de génération de schéma?

Je suppose qu'un tel travail serait exagéré s'il facilitait simplement les outils de génération de schémas, mais peut-être y a-t-il plus d'utilisations?

@Sanne

Eh bien, il existe une abstraction ici, appelée GenerationTarget . Nous pourrions peut-être mettre en œuvre cela, bien que je ne sois pas sûr à 100% de la manière exacte dont on procède pour en brancher un.

À défaut, une chose que nous pourrions faire est de demander à l'outil d'exportation de schéma d'exporter un SCRIPT , puis d'envoyer simplement les commandes une par une à la base de données.

Nous pourrions peut-être mettre en œuvre cela, bien que je ne sois pas sûr à 100% de la manière exacte dont on procède pour en brancher un.

Le problème est que la liste de ces cibles semble être codée en dur, sans moyen évident d'en ajouter une nouvelle. Mais un petit correctif au noyau pourrait suffire à résoudre ce problème.

D'accord. Bien que ce ne soit toujours pas la priorité absolue, je reporterai la publication du prochain ORM autant que possible, donc au cas où quelqu'un trouverait le temps, nous pourrons inclure d'autres correctifs de dernière minute.

Pour référence, rappelez-vous que l'exécution de la sortie ne nous prend vraiment pas beaucoup de temps : environ 20 minutes. Mais ensuite, nous devons attendre la synchronisation centrale de Maven et tout cela avant de pouvoir réellement l'utiliser :(
Ce qui implique que nous devons libérer environ 24h avant qu'une version réactive soit possible.

Je vais mettre de côté un peu de temps pour essayer cela. C'est peut-être super simple. Nous allons le découvrir.

C'est peut-être super simple. Nous allons le découvrir.

Donc, en effet, c'était relativement simple, mais cela a soulevé un problème que je n'avais pas envisagé : Hibernate Reactive n'a plus accès aux métadonnées JDBC, ce qui a des conséquences, mais je ne pense pas qu'elles soient trop terribles. Heureusement, Hibernate a été écrit lorsque les métadonnées JDBC étaient très peu fiables et n'en dépendaient pas vraiment.

Je suppose que c'est OK.

Il a également exposé un bogue dans ForeignKeys où Hibernate Reactive utilisait en fait la connexion JDBC pour obtenir des instantanés de la base de données ! Je vais ouvrir un rapport de bogue séparé pour ce problème.

Génial merci!

Le correctif de Gavin a été fusionné dans ORM; la création de schéma devrait être faisable maintenant.

Je soupçonne cependant que la mise à jour automatisée du schéma est un peu plus compliquée - pouvons-nous convenir que c'est moins important pour la première coupe?

Le correctif de Gavin a été fusionné dans ORM; la création de schéma devrait être faisable maintenant.

Merci.

Je soupçonne que la mise à jour automatisée du schéma est un peu plus compliquée cependant

Oh, beaucoup plus difficile, puisque l'implémentation actuelle est entièrement basée sur les métadonnées JDBC, IIRC.

pouvons-nous convenir que c'est moins important pour la première coupe?

Oui, je n'ai aucune intention de travailler là-dessus à ce stade. Je ne pense pas non plus que ce soit nécessaire.

@Sanne combien de temps avant que nous obtenions une version du noyau ORM avec ce changement?

@gavinking nous pouvons planifier une sortie lundi. Je me demande cependant - s'il y a plus de changements éventuellement nécessaires, peut-être vaut-il mieux différer?
Nous travaillons également sur d'autres correctifs dont Quarkus a besoin. Ainsi, même si nous pouvons en publier un quand nous le souhaitons, le plus tard sera le plus de correctifs.

@Sanne Non, tiens bon, ce commentaire a été fait avant que je découvre la gravité du 113.

@gavinking, à un moment donné, pourriez-vous rédiger un problème sur Vertx-sql-client décrivant les types de métadonnées de base de données nécessaires à Hibernate? Le client Vertx devrait avoir un jour une meilleure API de métadonnées qu'elle ne le fait actuellement.

+1 pour André !

Nous avons une initiative pour créer une API de récupération de métadonnées pour Postgres dans
https://github.com/eclipse-vertx/vertx-sql-client/pull/513. Les retours seront
certainement nous aider à construire une meilleure API générique autour de cela.

Le jeu. 14 mai 2020 à 21:58 Andrew Guibert [email protected]
a écrit:

@gavinking https://github.com/gavinking à un moment donné pourriez-vous écrire
un problème sur Vertx-sql-client décrivant quelles sortes de métadonnées de base de données sont
besoin d'Hibernate ? Le client Vertx devrait avoir une meilleure API de métadonnées
qu'il ne le fait actuellement un jour.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/hibernate/hibernate-reactive/issues/104#issuecomment-628654875 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

Ce dont les outils de gestion de schéma ont besoin, c'est d'un accès aux informations dans information_schema.tables et je suppose aussi dans information_schema.key_column_usage .

Ce dont les outils de gestion de schéma ont besoin, c'est d'un accès aux informations dans information_schema.tables et je suppose aussi dans information_schema.key_column_usage .

Notez qu'une option consiste à obtenir ces informations directement en interrogeant le information_schema . Historiquement, il s'agissait uniquement de l'API de métadonnées JDBC pour cela, afin de s'éloigner des différences de plate-forme.

C'est fait!

Et c'est fait d'une manière assez transparente pour l'utilisateur : s'il a configuré un pilote JDBC ou un pool de connexions, Hibernate ORM effectuera l'exportation de schéma sur JDBC mais s'il n'a pas de pilote JDBC, puis l'exportation de schéma sur JDBC le pilote Vert.x sera activé.

C'est génial!
Merci beaucoup

Et c'est fait d'une manière assez transparente pour l'utilisateur : s'il a un pilote JDBC ou un pool de connexions configuré, alors Hibernate ORM effectuera l'exportation de schéma sur JDBC mais _iff_ ils n'ont pas de pilote JDBC, puis l'exportation de schéma sur le pilote Vert.x sera activé.

juste curieux, pourquoi devrait-il essayer d'abord d'utiliser l'approche JDBC ? Si nous avons la possibilité de l'exécuter sur vertex, pourquoi ne pas le faire toujours ?

Cela peut être déroutant pour les utilisateurs si différents comportements sont déclenchés simplement parce qu'une connexion non liée est en cours de configuration. Aussi - comment savoir si cette autre connexion pointe vraiment vers la même base de données ?

juste curieux, pourquoi devrait-il essayer d'abord d'utiliser l'approche JDBC ? Si nous avons la possibilité de l'exécuter sur vertex, pourquoi ne pas le faire toujours ?

Eh bien, si vous avez configuré Hibernate standard avec un pilote JDBC standard, pourquoi ne pas l'utiliser ? L'exportation de schéma réactif n'est pas une chose significative. Pour que cela fonctionne, nous devons faire un join() totalement méchant à la fin, ce que Vert.x trouve assez bouleversant.

comment savoir si cette autre connexion pointe vraiment vers la même base de données ?

Parce que c'est la même URL JDBC ?

Cette page vous a été utile?
0 / 5 - 0 notes