Est-il possible d'exécuter des applications Hibernate configuré avec hbm2ddl.auto=update de mettre à jour le schéma de base de données dans un environnement de production?
Réponses
Trop de publicités?
Non, C'est dangereux.
Malgré les gens en veille prolongée de faire de leur mieux, vous ne pouvez pas compter sur les mises à jour automatiques en production. Écrire vous même les patchs, les passer en revue avec DBA, les tester, puis les appliquer manuellement.
Théoriquement, si hbm2ddl mise à jour travaillé dans le développement, il faut travailler dans la production de trop. Mais en réalité, il n'est pas toujours le cas.
Même si elle a travaillé OK, il peut être sous-optimale. Administrateurs de bases de données sont payés beaucoup pour une raison.
Brian Deterling
Points
7778
Nous le faisons dans la production, mais avec une application qui n'est pas essentiel à la mission et pas très bien payé, Administrateurs de bases de données sur le personnel. C'est juste un de moins processus manuel qui est sujet à l'erreur humaine - l'application peut détecter la différence et de faire la bonne chose, de plus, vous avez sans doute testé dans différents environnements de test et de.
Une mise en garde - dans un environnement en clusters, vous voudrez peut-être éviter parce que plusieurs applications peuvent venir en même temps et d'essayer de modifier le schéma qui pourrait être mauvais. Ou de mettre en place un mécanisme où une seule instance est autorisé à mettre à jour le schéma.
Roman
Points
361
Hibernate créateurs décourager de le faire dans un environnement de production dans leur livre "Java Persistance avec Hibernate":
AVERTISSEMENT: Nous avons vu les utilisateurs d'Hibernate en essayant d'utiliser SchemaUpdate pour mettre à jour le schéma d'une base de données de production automatique. Cela peut rapidement mettre fin à la catastrophe et ne sera pas autorisée par le DBA.
orange80
Points
5822
Découvrez LiquiBase XML pour garder un changelog de la mise à jour. Je n'avais jamais utilisé jusqu'à cette année, mais j'ai trouvé qu'il est très facile à apprendre et à faire des DB de contrôle de révision/migration/gestion du changement très à toute épreuve. Je travaille sur un Groovy/Graal projet, et le Graal utilise Hibernate-dessous pour l'ensemble de ses ORM (appelé "GORM"). Nous utilisons Liquibase de gérer tous les composants de SQL modifications de schéma, ce que nous faisons assez souvent que notre application mobile évolue avec de nouvelles fonctionnalités.
Fondamentalement, vous gardez un fichier XML de révisions que vous continuez à ajouter à votre application évolue. Ce fichier est conservé dans git (ou ce que vous utilisez), avec le reste de votre projet. Lorsque votre application est déployée, Liquibase vérifie son changelog de la table dans la base de données vous connecter afin de savoir ce qui a déjà été appliquée, alors intelligemment juste s'applique quelles que soient les modifications n'ont pas encore été appliqués à partir du fichier. Il fonctionne absolument génial dans la pratique, et si vous l'utiliser pour toutes vos modifications de schéma, alors vous pouvez être confiant à 100% que le code de commande et de déployer serez toujours en mesure de se connecter à un entièrement compatible schéma de base de données.
La chose est que je peux prendre un totalement vide de base de données mysql sur mon ordinateur portable, lancez l'application, et tout de suite le schéma est mis en place pour moi. Il permet également de tester les modifications de schéma en l'appliquant à un local-dev ou la mise en scène db première.
Le moyen le plus facile pour commencer avec, il serait probablement prendre votre base de données existante et ensuite utiliser Liquibase pour générer une première baseline.xml fichier. Puis dans le futur, vous pouvez simplement ajouter et laisser liquibase reprendre la gestion des modifications de schéma.
cliff.meyers
Points
10394
Je ne vote pas. Hibernate ne semblent pas comprendre quand les types de données pour les colonnes ont changé. Exemples (à l'aide de MySQL):
String with @Column(length=50) ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)
@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed
Il y a probablement d'autres exemples, tels que pousser la longueur d'une Chaîne de colonne de plus de 255 et voir de convertir en texte, mediumtext, etc etc.
Certes, je ne pense pas qu'il y est vraiment un moyen de "convertir les types de données" sans la création d'une nouvelle colonne, la copie de données et en soufflant de l'ancienne colonne. Mais à la minute où votre base de données a des colonnes qui ne reflètent pas le courant Hibernate mapping vous vivez très dangereusement...
La voie de migration est une bonne option pour traiter ce problème:
