Comment fonctionne le printemps.jpa.mise en veille prolongée.ddl-auto propriété exactement travaux au Printemps?

Je travaillais sur mon Ressort de démarrage de projet d'application et a remarqué que, parfois, il y a un délai de connexion erreur de ma Base de données sur un autre serveur(SQL Server).
Cela se produit en particulier lorsque j'essaie de faire un script de migration avec FlyWay mais il fonctionne après plusieurs tentatives.

Puis j'ai remarqué que je n'ai pas préciser spring.jpa.hibernate.ddl-auto dans mon fichier de propriétés. J'ai fait quelques recherches et trouvé qu'il est recommandé d'ajouter
spring.jpa.hibernate.ddl-auto= create-drop en développement.
Et à le modifier: spring.jpa.hibernate.ddl-auto= none dans la production.

Mais je n'ai pas vraiment compris comment ça marche vraiment et comment hibernate générer schéma de base de données à l'aide de create-drop ou none valeur. Pouvez-vous veuillez expliquer techniquement comment ça marche vraiment, et quelles sont les recommandations pour l'utilisation de cette propriété dans le développement et sur un serveur de production.
Merci

  • FWIW JPA 2.1 a un standard de la propriété javax.la persistance.schéma de génération.la base de données.action de manière à ne vois vraiment pas la nécessité d'utiliser JPA fournisseur des propriétés spécifiques pour génération de schéma.
  • Une idée que nous explorons avec Hibernate 6 est la capacité à être en mesure de contrôler la génération de schéma différemment selon les catégories; par exemple l'orm tables pourraient être none mais vous pourriez voulez que votre Hibernate Recherche et Envers les tables générées à l'aide de update car ils sont gérés à l'interne par ces projets et vous ne voulez pas pour les gérer manuellement vous-même. Maintenant nous avons le contrôle de cette globalement pour toutes les tables, indépendamment de leur origine/de source. Ce serait en outre la raison d'utiliser des options spécifiques au fournisseur si vous voulais l'utiliser.
InformationsquelleAutor METTAIBI | 2017-02-09
  1. 144

    Pour l'enregistrement, la spring.jpa.hibernate.ddl-auto propriété est le Printemps de Données JPA spécifiques et de leur façon de spécifier une valeur qui sera finalement adopté à Hiberner dans la propriété qu'il sait, hibernate.hbm2ddl.auto.

    Les valeurs create, create-drop, validate, et update fondamentalement influencer la façon dont le schéma de l'outil de gestion de manipuler le schéma de base de données au démarrage.

    Par exemple, la update opération de requête le pilote JDBC de l'API pour obtenir les métadonnées de base de données et puis Hibernate compare le modèle de l'objet qu'il crée, basée sur la lecture de votre annoté des classes ou des HBM XML mappages et va tenter de régler le schéma à la volée.

    La update opération pour exemple tente d'ajouter de nouvelles colonnes, contraintes, etc, mais ne jamais supprimer une colonne ou une contrainte qui peut avoir existé auparavant, mais pas plus que dans le cadre du modèle d'objet à partir d'un avant terme.

    Généralement en cas de test de scénarios, vous aurez probablement utiliser create-drop de sorte que vous créez votre schéma, votre cas de test ajoute certains se moquer de données, de l'exécution des tests, et ensuite au cours de l'essai de nettoyage, les objets de schéma sont tombé, laissant un vide de la base de données.

    En développement, il est souvent fréquent de voir les développeurs utilisent update de modifier automatiquement le schéma d'ajouter de nouveaux ajouts au moment du redémarrage. Mais encore une fois comprendre, ce n'est pas supprimer une colonne ou une contrainte qui peut exister des exécutions précédentes qui n'est plus nécessaire.

    Dans la production, il est fortement recommandé que vous utilisez none ou tout simplement ne spécifie pas cette propriété. C'est parce qu'il est de pratique courante pour les Administrateurs de base de données pour examiner les scripts de migration pour les modifications de base de données, en particulier si votre base de données est partagée entre plusieurs services et applications.

    • Oui, ne jamais utiliser de ddl génération dans la production. Nous générer les premiers scripts de la structure de la table à l'aide de ddl, et d'impliquer le DBA dans le processus. Nous avons ensuite inclure la db scripts dans le cadre de l'unité de déploiement, et de les exécuter à l'aide de la voie de migration lorsque l'application est déployée. Lorsque nous avons besoin de modifier la base de données, nous ajoutons de nouveaux scripts pour la prochaine version de l'application et la déployer à la mise en scène. La voie de migration détecte automatiquement la version actuelle et exécuter les scripts nécessaires pour mettre la base de données de la version la plus récente. Si tout fonctionne à nous déployer en production.
    • que faire si l'on ne spécifie pas cette propriété? par exemple, j'ai mon propre <bean id="sessionFactory" class="org.springframework.orm.hibernate5.LocalSessionFactoryBean"> ... <prop key="hibernate.hbm2ddl.auto">mise à jour</prop> j'ai eu cette et pour quelque raison que mes tables ont été larguaient toujours, jusqu'à ce que j'ai ajouté ci-dessus mentionné de propriété;; ps: désolé pour l'exemple de code )
    • J'ai eu H2 et le printemps de démarrage a décidé qu'il fallait utiliser "create-drop", et je suppose que cela remplace mes biens que j'ai mis docs.printemps.io/spring-boot/docs/current/reference/html/...
    • Pourquoi ne pas validate dans la Production Env?
    • Les Applications peuvent utiliser validate dans la production, mais en général, qui devrait être un paramètre que vous utilisez dans votre qualité/environnement de test pour vérifier que les scripts de base de données que vous avez écrit ou appliqué à votre base de données de l'outil de migration sont exacts. Une autre raison de ne pas utiliser validate dans la production, c'est qu'il pourrait être un goulot d'étranglement pendant le processus de démarrage de votre application, en particulier si votre modèle d'objet est assez vaste dans la taille ou si le réseau de facteurs entrent en jeu.
    • Je suis l'aide de la variable de mises à jour, mais une erreur quand j'ai essayé d'ajouter une nouvelle colonne "ordre" (datatype = Long) dans ma classe du modèle de la galerie : org.mise en veille prolongée.outil de.schéma.le spi.SchemaManagementException: Impossible d'exécuter la gestion des schémas de JDBC cible [alter table galerie d'ajouter de l'ordre de la colonne bigint ]
    • Sans un précis de la trace de la pile il est difficile de spéculer; cependant, ma première hypothèse serait que order est mal interprétée par le moteur SQL puisque c'est un mot clé si elle n'est pas échappé.

    InformationsquelleAutor Naros