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

Es ist keine gute Idee, die hbm2ddl.auto in der Produktion.

Die einzige Möglichkeit, das Datenbankschema zu verwalten, ist die Verwendung inkrementeller Migrationsskripte, denn:

• werden die Skripte zusammen mit Ihrer Codebasis im VCS gespeichert. Wenn Sie einen Zweig auschecken, erstellen Sie das gesamte Schema von Grund auf neu.
• die inkrementellen Skripte können auf einem QA-Server getestet werden, bevor sie in der Produktion eingesetzt werden
• Es besteht kein Bedarf an manuellen Eingriffen, da die Skripte von der Kommission ausgeführt werden können. Flugroute Dadurch wird die Möglichkeit menschlicher Fehler bei der manuellen Ausführung von Skripten verringert.

Auch die Hibernate Benutzerhandbuch raten wir Ihnen, die Verwendung des hbm2ddl Werkzeug für Produktionsumgebungen.

Answer 2

Ich würde mit Nein stimmen. Hibernate scheint nicht zu verstehen, wenn sich Datentypen für Spalten geändert haben. Beispiele (unter Verwendung von 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

Wahrscheinlich gibt es noch andere Beispiele, wie z. B. das Erhöhen der Länge einer String-Spalte auf über 255 und die Umwandlung in Text, Mediumtext usw. usw.

Zugegeben, ich glaube nicht, dass es wirklich eine Möglichkeit gibt, "Datentypen zu konvertieren", ohne eine neue Spalte zu erstellen, die Daten zu kopieren und die alte Spalte zu vernichten. Aber sobald Ihre Datenbank Spalten enthält, die nicht dem aktuellen Hibernate-Mapping entsprechen, leben Sie sehr gefährlich...

Flyway ist eine gute Möglichkeit, dieses Problem zu lösen:

http://flywaydb.org

Answer 3

Ich würde es nicht riskieren, denn es könnten Daten verloren gehen, die eigentlich erhalten bleiben sollten. hbm2ddl.auto=update ist lediglich eine einfache Möglichkeit, Ihre Entwicklungsdatenbank auf dem neuesten Stand zu halten.

Answer 4

Wir machen das in einem Projekt, das seit Monaten in Produktion ist, und hatten bisher noch nie ein Problem. Denken Sie an die 2 Zutaten, die für dieses Rezept benötigt werden:

1. Entwerfen Sie Ihr Objektmodell mit einem Ansatz der Rückwärtskompatibilität, d.h. verwerfen Objekte und Attribute, anstatt sie zu entfernen oder zu ändern. Das heißt, wenn Sie den Namen eines Objekts oder Attributs ändern müssen, lassen Sie den alten Namen unverändert, fügen den neuen hinzu und schreiben eine Art Migrationsskript. Wenn Sie eine Assoziation zwischen Objekten ändern müssen, die sich bereits in der Produktion befindet, bedeutet dies, dass Ihr Entwurf von vornherein falsch war; versuchen Sie also, eine neue Art und Weise zu finden, die neue Beziehung auszudrücken, ohne alte Daten zu beeinträchtigen.

2. Immer Backup die Datenbank vor der Bereitstellung.

Nach der Lektüre dieses Beitrags habe ich das Gefühl, dass 90 % der Teilnehmer an dieser Diskussion allein bei dem Gedanken an den Einsatz solcher Automatisierungen in einer Produktionsumgebung entsetzt sind. Einige den Ball werfen bei der DBA. Bedenken Sie jedoch, dass nicht alle Produktionsumgebungen einen DBA bereitstellen, und dass sich nicht viele Entwicklerteams einen DBA leisten können (zumindest nicht für mittelgroße Projekte). Wenn es sich also um Teams handelt, in denen jeder alles machen muss, liegt der Ball bei ihnen.

Warum sollte man in diesem Fall nicht einfach versuchen, das Beste aus beiden Welten zu bekommen? Werkzeuge wie dieses sind dazu da, eine helfende Hand zu geben, die - mit einem sorgfältigen Design und Plan - in vielen Situationen helfen kann. Und glauben Sie mir, es mag anfangs schwer sein, Verwaltungsangestellte zu überzeugen, aber wenn sie wissen, dass der Ball nicht in ihren Händen liegt, werden sie es lieben.

Ich persönlich würde nie wieder Skripte für die Erweiterung eines Schemas von Hand schreiben, aber das ist nur meine Meinung. Und nachdem ich vor kurzem begonnen habe, schemafreie NoSQL-Datenbanken einzuführen, sehe ich, dass all diese schemabasierten Operationen mehr als bald der Vergangenheit angehören werden, also sollten Sie besser anfangen, Ihre Perspektive zu ändern und nach vorne zu schauen.

Answer 5

• In meinem Fall (Hibernate 3.5.2, Postgresql, Ubuntu) ist die Einstellung hibernate.hbm2ddl.auto=update nur neue Tabellen erstellt und neue Spalten in bereits vorhandenen Tabellen angelegt.

• Es wurden weder Tabellen gelöscht, noch Spalten gelöscht, noch Spalten geändert. Es kann als eine sichere Option bezeichnet werden, aber etwas wie hibernate.hbm2ddl.auto=create_tables add_columns wäre klarer.