Hibernate: hbm2ddl.auto=update in der Produktion?

Question

Ist es in Ordnung, Hibernate-Anwendungen auszuführen, die mit hbm2ddl.auto=update um das Datenbankschema in einer Produktionsumgebung zu aktualisieren?

Answer 1

Nein, es ist unsicher.

Trotz aller Bemühungen des Hibernate-Teams können Sie sich nicht auf automatische Updates verlassen. in Produktion . Schreiben Sie Ihre eigenen Patches, prüfen Sie sie mit dem DBA, testen Sie sie und wenden Sie sie dann manuell an.

Theoretisch, wenn hbm2ddl-Aktualisierung in der Entwicklung funktioniert hat, sollte es auch in der Produktion funktionieren. Aber in der Realität ist das nicht immer der Fall.

Selbst wenn es gut funktioniert, kann es suboptimal sein. DBAs werden nicht ohne Grund so gut bezahlt.

Answer 2

Wir machen das in der Produktion, wenn auch mit einer Anwendung, die nicht unternehmenskritisch ist, und ohne hochbezahlte DBAs im Team. Es ist nur ein manueller Prozess weniger, der menschlichen Fehlern unterliegt - die Anwendung kann den Unterschied erkennen und das Richtige tun, und Sie haben es vermutlich in verschiedenen Entwicklungs- und Testumgebungen getestet.

Eine Einschränkung - in einer Cluster-Umgebung sollten Sie dies vermeiden, da mehrere Anwendungen gleichzeitig auftauchen und versuchen können, das Schema zu ändern, was schlecht sein könnte. Oder Sie sollten einen Mechanismus einrichten, der es nur einer Instanz erlaubt, das Schema zu aktualisieren.

Answer 3

Die Entwickler von Hibernate raten in ihrem Buch davon ab, dies in einer Produktionsumgebung zu tun "Java-Persistenz mit Hibernate" :

WARNUNG: Wir haben gesehen, wie Hibernate-Benutzer versucht haben, mit SchemaUpdate das Schema einer Produktionsdatenbank automatisch zu aktualisieren. Dies kann schnell in einer Katastrophe enden und wird von Ihrem DBA nicht erlaubt.

Answer 4

Hibernate muss den Disclaimer über die Nichtverwendung von automatischen Updates in Prod einfügen, um sich abzusichern, wenn Leute, die nicht wissen, was sie tun, es in Situationen verwenden, in denen es nicht verwendet werden sollte.

Zugegeben, es gibt weitaus mehr Situationen, in denen sie nicht verwendet werden sollte, als solche, in denen sie in Ordnung ist.

Ich benutze es seit Jahren für viele verschiedene Projekte und hatte noch nie ein einziges Problem. Das ist keine lahme Antwort, und es ist keine Cowboy-Kodierung. Es ist eine historische Tatsache.

Jemand, der sagt: "Mach das nie in der Produktion", denkt an eine bestimmte Gruppe von Produktionseinsätzen, nämlich die, mit denen er vertraut ist (sein Unternehmen, seine Branche usw.).

Die Welt der "Produktionseinsätze" ist groß und vielfältig.

Ein erfahrener Hibernate-Entwickler weiß genau, welche DDL sich aus einer bestimmten Mapping-Konfiguration ergibt. Solange Sie testen und validieren, dass das, was Sie erwarten, in der DDL landet (in Dev, QA, Staging usw.), ist alles in Ordnung.

Wenn Sie viele Funktionen hinzufügen, können automatische Schema-Updates eine echte Zeitersparnis sein.

Die Liste der Dinge, die automatische Aktualisierungen nicht verarbeiten können, ist endlos, aber einige Beispiele sind Datenmigration, Hinzufügen von Spalten, die nicht mit Nullen belegt werden können, Änderungen von Spaltennamen usw. usw.

Auch in geclusterten Umgebungen ist Vorsicht geboten.

Aber wenn du das alles wüsstest, würdest du diese Frage nicht stellen. Hmm . . . OK, wenn Sie diese Frage stellen, sollten Sie warten, bis Sie viel Erfahrung mit Hibernate und automatischen Schema-Updates haben, bevor Sie darüber nachdenken, es in der Produktivumgebung einzusetzen.

Answer 5

Schauen Sie sich LiquiBase XML an, um ein Änderungsprotokoll der Updates zu führen. Ich hatte es bis zu diesem Jahr noch nie benutzt, aber ich habe festgestellt, dass es sehr einfach zu erlernen ist und die DB-Revisionskontrolle/Migration/Änderungsverwaltung sehr narrensicher macht. Ich arbeite an einem Groovy/Grails-Projekt, und Grails verwendet Hibernate für sein gesamtes ORM (genannt "GORM"). Wir verwenden Liquibase, um alle SQL-Schema-Änderungen zu verwalten, die wir ziemlich oft tun, wie unsere App mit neuen Funktionen entwickelt.

Im Grunde genommen führen Sie eine XML-Datei mit Changesets, die Sie im Laufe der Entwicklung Ihrer Anwendung immer wieder ergänzen. Diese Datei wird in Git (oder was auch immer Sie verwenden) zusammen mit dem Rest Ihres Projekts gespeichert. Wenn Ihre Anwendung bereitgestellt wird, prüft Liquibase die Changelog-Tabelle in der DB, mit der Sie sich verbinden, damit es weiß, was bereits angewendet wurde. In der Praxis funktioniert das hervorragend, und wenn Sie es für alle Ihre Schemaänderungen verwenden, können Sie zu 100 % sicher sein, dass der Code, den Sie auschecken und bereitstellen, sich immer mit einem vollständig kompatiblen Datenbankschema verbinden kann.

Das Tolle daran ist, dass ich eine völlig leere Mysql-Datenbank auf meinem Laptop nehmen kann, die App starten kann und das Schema sofort für mich eingerichtet ist. Es macht es auch einfach, Schemaänderungen zu testen, indem man sie zuerst auf eine lokale Entwicklungs- oder Staging-Datenbank anwendet.

Der einfachste Weg, damit anzufangen, wäre wahrscheinlich, Ihre bestehende DB zu nehmen und dann Liquibase zu verwenden, um eine erste baseline.xml-Datei zu erzeugen. In Zukunft können Sie dann einfach etwas hinzufügen und Liquibase die Verwaltung von Schemaänderungen überlassen.

http://www.liquibase.org/