Wie kann ich meine Datenbank unter Versionskontrolle mit Perl bekommen?

Question

Ich habe die Optionen zum Abrufen unserer Datenbankschemas unter Versionskontrolle untersucht. Es scheint, dass Ruby Leute haben Rails Migrations, und .NET Leute haben ein paar Optionen (zum Beispiel this, this und this). Was ist mit Perl?

Ich habe dieses thread on PerlMonks gesehen, das nicht viel hat, obwohl es DBIX::Migration::Directories erwähnt. Nutzt tatsächlich jemand dieses Modul oder ein anderes Modul? Oder rollen Sie Ihre eigenen DB-Migrationslösungen?

Gratuitous Details:

• Wir tun nicht Verwendung DBIx :: Class zum größten Teil
• Wir verwenden MySQL
• Wir SVN verwenden

Answer 1

In POPFile wir verwenden unsere eigene Lösung. Wir speichern eine Schema-Versionsnummer in der Datenbank und wenn das Programm erkennt, dass es ein neueres Schema gibt, wird es die Datenbank entsprechend aktualisieren. Dies ist nicht gerade der beste und unterhaltsamste Teil unseres Codes.

Um ehrlich zu sein, sehe ich nicht den Vorteil der Verwendung von DBIx :: Migration :: Verzeichnisse, wenn Sie nicht bereits DBIx :: Class verwenden. Sie müssen die SQL- und die Versionsnummern und das Datenbank-Handle angeben. Sie könnten auch ein wenig mehr Code zur Verfügung stellen, um die SQL-Datei zu finden und sie der Datenbank zuzuführen.

Natürlich ist das Schema in der Versionskontrolle ein großer Bonus.

Answer 2

Ein sehr interessantes Projekt, auf das man sich wahrscheinlich noch ein wenig verlassen kann, ist Adam Kennedys ORLite::Migrate, das seine Inspiration aus den Migrationen von Rails bezieht. Er hat wrote up a very interesting journal über auf use.perl.org über seine Pläne und ich hoffe, es für die Zukunft im Auge zu behalten.

Es scheint, dass dieses Paket nur mit SQLite im Moment funktioniert, aber ich denke, dass Adam plant, dies zu bauen, um zukünftig datenbankunabhängig zu sein.

Answer 3

Wir verwenden ein ähnliches System wie Manni beschrieben. Die beiden großen Nachteile sind:

• nicht Schemaänderungen Rollback kann (in der Regel ist dies selten, nicht gut getestet und hart sowieso so hat es zu tun manuell ist keine große Sache IMO).

• Die Verwendung einer sequentiellen Versionsnummer ist ein Problem, wenn Sie in mehreren Zweigen entwickeln - da Sie SVN verwenden, ist dies nicht so wahrscheinlich ein Problem, als wenn Sie git verwenden würden. :-)

Das Skript Skript, das ich hier verwenden: database_update und es gibt einen kleinen example data file.

Answer 4

Bei der Arbeit verwenden wir eine modifizierte Version von DBIx::Migration (es hat einige Einschränkungen, wie nicht mehr als 10 Migrationen). Dann haben Sie ein Kernschema, das Sie von Ihrer Datenbank ausgegeben haben, und wenn die Versionsnummer zu niedrig ist, aktualisieren Sie Ihre Datenbank mithilfe der Migrationen aus dem Migrationsschemaverzeichnis.

Ich empfehle auch das Database Refactoring Buch.Unter anderem gibt es Ihnen hervorragende Techniken zum Verwalten von Migrationen sicher in der Weise, dass Sie keine Daten verlieren, wenn Sie ein Rollback durchführen müssen (z. B. wenn Sie eine Spalte löschen, die Sie nicht benötigen) .

Um die automatischen Abschreibungszeitpläne zu unterstützen, habe ich vorgeschlagen, Devel::Deprecate zu schreiben, damit Sie sich nicht daran erinnern müssen, wann die Abwertungen durchgeführt werden sollen. Ihr Code wird sich lautstark für Sie beschweren (und nur im Test, nicht in der Produktion).

Wichtige: Sie werden regelmäßig feststellen, dass Sie so viele Datenbankmigration Ebenen mit dieser Technik anwenden möchten, dass Sie manchmal werden müssen „bump up“ Ihre minimale Basis Migration, weil es zu lange dauert, um wieder aufzubauen die Datenbank. Nehmen Sie einfach einen neuen Dump der Datenbank auf der gewünschten Migrationsebene und entfernen Sie alle Migrationen, die kleiner oder gleich dieser Ebene sind.

aktualisieren: Schneller Vorlauf ein paar Jahren und ich heute empfehlen sqitch. Es wurde von Grund auf entwickelt, um eine Datenbank unter Versionskontrolle zu stellen, ohne Sie an eine bestimmte Programmiersprache oder VCS zu binden.

Answer 5

Es gibt ein interessantes CPAN-Modul (Database::Migrator). Ich habe es verwendet und funktioniert gut, um die Migrationen Ihres Projekts zu bewältigen.

Jede Migration wird in ein eigenes Verzeichnis übertragen. Migrationen werden in sortierter Reihenfolge angewendet. In der Regel benennen Sie sie mit einem Nummernpräfix. Das Migrationsverzeichnis kann Dateien mit SQL oder Perl enthalten.

Answer 6

Wie wäre es mit ? Es wirbt selbst als "Datenbank-Change-Management-Anwendung",