Sqldef: Idempotentes Schema-Management-Tool für MySQL, PostgreSQL und SQLite

• CLI-basiertes Tool zur Verwaltung von Datenbankmigrationen durch Vergleich der Unterschiede (Diffs) zwischen SQL-Schemata
• RDBMS-Schemata lassen sich mit der üblichen SQL-DDL-Syntax verwalten
• Unterstützt wichtige Datenbanken wie MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3
• Auf der Website lässt sich über eine Online-Demo mit WebAssembly-Build der Schema-Vergleich und die DDL-Erzeugung ausprobieren
• Datenbankänderungen können idempotent verwaltet werden, was für eine zuverlässige Schema-Synchronisierung nützlich ist

---

Überblick über sqldef

• sqldef ist ein CLI-Tool, das zwei SQL-Schemata vergleicht (Diff), Unterschiede analysiert und darauf basierend DDL-Anweisungen erzeugt
  • Nutzer können bestehende und gewünschte Ziel-Schemata vergleichen und die erforderlichen Änderungen automatisch ableiten
  • Migrationen können mit der üblichen SQL-DDL-Syntax direkt durchgeführt werden
• Als unterstützte Datenbanken werden MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3 genannt

Funktionen der Online-Demo

• Auf der Website gibt es eine Online Demo, mit der sich Schemaänderungen visuell nachvollziehen lassen
  • Über die Option „Enable DROP“ lässt sich steuern, ob Löschanweisungen einbezogen werden
  • Im Abschnitt „Up (current → desired)“ werden Beispiel-DDLs wie das Hinzufügen neuer Spalten, das Erstellen von Indizes oder das Hinzufügen von Constraints angezeigt
  • Im Abschnitt „Down (desired → current)“ werden Beispiele für Rückwärtsänderungen wie das Entfernen von Constraints gezeigt

Funktionsweise

• Die Online-Demo verwendet den WebAssembly-Build von sqldef, um SQL-Schema-Vergleiche (Diffs) direkt im Browser auszuführen
  • Die Unterschiede zwischen zwei Schemata werden berechnet und daraus automatisch die benötigten DDL-Anweisungen erzeugt
  • Über den Link zum GitHub-Repository lässt sich der Quellcode des WebAssembly-Builds einsehen

[GN⁺]

Hacker-News-Kommentare

• Wenn du für Postgres eine umfassendere Abdeckung möchtest, könnte sich ein Blick auf pgschema lohnen, das ich entwickelt habe
  Letzten Sommer dachte ich, es sei ziemlich fertig, aber nachdem ich in sechs Monaten über 100 Issues behoben habe, die Nutzer gemeldet hatten, wurde mir klar, wie naiv ich war

  • Wirklich tolles Tool. Wir wollen mit unserem Team dazu einen PoC bauen
    Ich frage mich, ob es auch unterstützt, Inkonsistenzen über mehrere Datenbank-Cluster hinweg zu prüfen
  • Erinnert mich an Migra
  • Sieht gut für Schema-Migrationen aus, aber ich frage mich, wie mit update/insert umgegangen wird, wenn tatsächlich Daten verschoben werden müssen
  • Auch Xatas pg_roll könnte eine Alternative sein

• Ich habe es mit SQLite getestet, und bei schwierigen Migrationen, bei denen Foreign-Key-Constraints zu bestehenden Tabellen hinzugefügt werden, erzeugt es ungültiges SQL
  Zum Beispiel ist eine Syntax wie ALTER TABLE books ADD CONSTRAINT fk_books_author FOREIGN KEY (author_id) REFERENCES authors (id) in SQLite nicht erlaubt
  Siehe dazu die Dokumentation: SQLite ALTER TABLE

  • Bedeutet das am Ende, dass man zum Hinzufügen eines Foreign Keys die Spalte löschen und erneut hinzufügen muss?

• Ich verwende Atlas
  Migrationsbasiert und schemabasiert haben beide Vor- und Nachteile, daher nutze ich in einem Projekt beide Ansätze parallel
  Der schemabasierte Ansatz erhöht die Entwicklungsgeschwindigkeit, und der migrationsbasierte Ansatz ermöglicht verlässlichere Deployments

  • Hier ist Ariel vom Atlas-Team. Lokal ist ein deklarativer Ansatz üblich, in realen Umgebungen ein versionierter Ansatz parallel dazu
    Da Atlas in PRs automatisch Migrationen erzeugt, müssen die meisten Entwickler den versionierten Workflow nicht direkt anfassen
    Relevante Dokumentation: Declarative vs Versioned Workflows, Atlas Action
  • Ich habe mir auch sqldef und andere Alternativen angesehen und bin dann auf Atlas gestoßen
    Mir gefiel die explizite Unterstützung für einen Migration Flow. Ich möchte vor einem echten Deployment genau wissen, welche Änderungen angewendet werden

• Ich frage mich, ob es ein gutes Tool gibt, das Background-Migrationen unterstützt
  Zum Beispiel fügt man einer großen Tabelle eine temporäre nullable Spalte hinzu, neuer Code beginnt, Daten in diese Spalte zu schreiben, dann werden die bestehenden Daten im Hintergrund in Batches aufgefüllt, und am Ende wird die Spalte auf non-nullable geändert
  Es wäre gut, ein Tool zu haben, mit dem sich solche prozeduralen Änderungen deklarativ ausdrücken und zusammen mit dem Code reviewen und testen lassen
  Derzeit wird das meist mit temporären Skripten und manuellen Deployment-Anweisungen gelöst

  • Ich schreibe Schema-Migrationen eher selbst, verwende aber meistens grate
    Im Entwicklungsumfeld ist die Einrichtung einfach, und es gibt Beispiele wie FastEndpoints-SqlJobQueues

• Wirklich ein tolles Tool
  Dank ihm kann ich mein Hobbyprojekt aufgeben, mit dem ich dieselbe Funktion bauen wollte
  Stattdessen starte ich ein anderes neues Projekt zu einem Problem, das bestimmt schon hundertmal gelöst wurde — etwa ein einfaches Tool, das systemd-Logs überwacht und Fehler per E-Mail verschickt

• Ich fand es schön, dass das nicht noch ein weiterer Migrationsmanager ist, sondern ein kleines, nützliches Tool
  Es fühlt sich an, als würde es die Schwächen von SQL gut ausgleichen. Ich denke auch, es wäre schön, wenn es so deklarativ wie Spanner DDL wäre
  In Postgres versuche ich, Schema-Skripte idempotent zu halten. Ich beginne mit CREATE TABLE IF NOT EXISTS und füge neue Spalten separat mit ALTER hinzu
  Mit der Zeit werden die Skripte aber komplex, und sobald sich alles stabilisiert hat, räume ich die ALTER-Anweisungen auf
  Wenn man einmal ein altes Backup wiederherstellen muss, könnte so ein Tool die Kompatibilität wohl schnell wieder angleichen

• Ich frage mich, wie es im Vergleich zu Entity Framework oder sqitch/liquibase abschneidet
  Den deklarativen Ansatz verstehe ich, aber bei großen Produktionsdatenbanken sind Migrationen nicht einfach nur deklarativ
  Ein idealer Schema-Manager müsste Abfragekosten und Strategien zur Minimierung von Downtime verstehen
  Das Hinzufügen von Spalten oder das Ändern von Indizes kann einen vollständigen Table-Scan auslösen

  • Das größere Problem ist, dass die Daten selbst Teil der Migration sein können
    Wenn man zum Beispiel Fullname in FirstName und LastName aufteilt, bildet ein einfacher Diff nur die Hälfte davon ab
    In EF Core werden reversible Transformationen mit Up/Down-Methoden behandelt
    Ich frage mich, wie Datenumwandlungen ohne ein solches Konzept gehandhabt werden

• Wir haben intern ein XML-basiertes Transformationstool gebaut
  XML ließ sich leichter parsen als SQL, daher vergleichen wir das in XML definierte Schema mit der Datenbank und wenden nur die nötigen Änderungen an
  Wir verwendeten Sybase SQLAnywhere, und wenn materialized views involviert waren, wurde das Hinzufügen oder Löschen von Spalten kompliziert, weil Views und Indizes neu erstellt werden mussten
  Deshalb haben wir Schutzmechanismen eingebaut, sodass das Löschen von Spalten nur explizit erlaubt ist und Typänderungen nur in sicheren Fällen durchgeführt werden
  Damit wurden Migrationen in Hunderten von On-Premises-Installationen sehr einfach
  Man ändert einfach das XML, das Tool erledigt den Rest, und bei Bedarf kann man Funktionen ergänzen

• Unter SQLite funktioniert das Löschen von Spalten nicht gut
  Erst in neueren Versionen wurde DROP COLUMN hinzugefügt, aber auf den meisten Geräten wird es noch immer nicht unterstützt
  Im Beispiel wurde x integer not null hinzugefügt und dann ein DROP versucht, aber es erschien nur die Meldung „-- Skipped“
  Die Standardmethode ist, eine temporäre Tabelle anzulegen, die Daten zu kopieren und dann zu ersetzen, aber dieses Tool automatisiert das nicht
  Wenn Constraints im Spiel sind, passieren dabei leicht Fehler, was schade ist
  Wenn am Ende ohnehin nur einfache Aufgaben erledigt werden, ist es vielleicht besser, es manuell zu machen

• Dieses Tool scheint nur für leere Datenbanken nützlich zu sein
  Datenmigrationen kann es nicht behandeln, und bei Tabellen mit realen Daten ist es unbrauchbar — etwa wenn eine JSONB-Spalte in eine strukturierte Form überführt wird oder wenn nach dem Löschen einer Spalte bei einer Rückwärtsmigration ADD COLUMN … NOT NULL erzeugt wird