Sqldef: alat pengelolaan skema idempoten untuk MySQL, PostgreSQL, dan SQLite

• Alat berbasis CLI untuk mengelola migrasi database dengan membandingkan diff antar skema SQL
• Dapat mengelola skema RDBMS menggunakan sintaks SQL DDL yang umum
• Mendukung database utama seperti MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3
• Situs webnya menyediakan demo online yang memanfaatkan build WebAssembly untuk mencoba perbandingan skema dan pembuatan DDL
• Perubahan database dapat dikelola secara idempoten (idempotent), sehingga berguna untuk sinkronisasi skema yang stabil

---

Gambaran umum sqldef

• sqldef adalah alat CLI yang membandingkan diff antara dua skema SQL, menganalisis perbedaannya, lalu menghasilkan perintah DDL berdasarkan hasil tersebut
  • Pengguna dapat membandingkan skema yang ada dengan skema target untuk secara otomatis memperoleh perubahan yang diperlukan
  • Migrasi dapat dijalankan dengan tetap menggunakan sintaks SQL DDL umum apa adanya
• Database yang didukung disebutkan sebagai MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3

Fitur demo online

• Situs web menyediakan Online Demo sehingga perubahan skema dapat dilihat secara visual
  • Melalui opsi “Enable DROP”, pengguna dapat mengatur apakah perintah penghapusan disertakan atau tidak
  • Di bagian “Up (current → desired)”, ditampilkan contoh DDL seperti penambahan kolom baru, pembuatan indeks, dan penambahan constraint
  • Di bagian “Down (desired → current)”, tersedia contoh perubahan arah balik seperti penghapusan constraint

Cara kerja

• Demo online menggunakan build WebAssembly milik sqldef untuk menjalankan perbandingan diff skema SQL di dalam browser
  • Perbedaan antara dua skema dihitung, lalu perintah DDL yang diperlukan dibuat secara otomatis dari hasilnya
  • Sumber build WebAssembly dapat dilihat melalui tautan repositori GitHub

[GN⁺]

Komentar Hacker News

• Jika menginginkan cakupan yang lebih komprehensif untuk Postgres, mungkin layak melihat pgschema yang saya buat
  Musim panas lalu saya sempat berpikir ini sudah cukup matang, tetapi setelah memperbaiki lebih dari 100 issue yang dilaporkan pengguna selama 6 bulan, saya sadar betapa naifnya saya

  • Alat yang sangat keren. Kami berencana membuat PoC bersama tim kami
    Saya penasaran apakah ini juga mendukung pemeriksaan ketidaksesuaian di beberapa klaster database
  • Mengingatkan saya pada Migra
  • Terlihat bagus untuk migrasi skema, tetapi saya penasaran bagaimana penanganan update/insert saat perlu memindahkan data yang sebenarnya
  • pg_roll dari Xata juga layak dipertimbangkan sebagai alternatif

• Saya mencobanya dengan SQLite, dan untuk migrasi sulit seperti menambahkan foreign key constraint ke tabel yang sudah ada, alat ini menghasilkan SQL yang tidak valid
  Sebagai contoh, sintaks seperti ALTER TABLE books ADD CONSTRAINT fk_books_author FOREIGN KEY (author_id) REFERENCES authors (id) tidak diizinkan di SQLite
  Lihat dokumentasi terkait di SQLite ALTER TABLE

  • Jadi pada akhirnya untuk menambahkan foreign key, apakah situasinya menjadi harus drop kolom lalu menambahkannya lagi?

• Saya menggunakan Atlas
  Baik pendekatan berbasis migrasi maupun berbasis skema punya kelebihan dan kekurangan, jadi saya memakai keduanya dalam satu proyek
  Pendekatan berbasis skema mempercepat pengembangan, dan pendekatan berbasis migrasi memungkinkan deployment yang lebih meyakinkan

  • Saya Ariel dari tim Atlas. Konfigurasi yang menggabungkan pendekatan deklaratif di lokal dan pendekatan versioned di lingkungan nyata cukup umum
    Karena Atlas otomatis membuat migrasi di PR, sebagian besar developer tidak perlu menangani workflow versioned secara langsung
    Dokumentasi terkait: Declarative vs Versioned Workflows, Atlas Action
  • Saya juga menemukan Atlas setelah melihat sqldef dan alternatif lainnya
    Saya suka karena ada dukungan migration flow yang eksplisit. Saya ingin tahu persis perubahan apa yang akan diterapkan sebelum deployment sungguhan

• Saya penasaran apakah ada alat yang bagus yang mendukung background migration
  Misalnya, menambahkan kolom nullable sementara ke tabel besar, lalu kode baru mulai menulis data ke kolom itu, kemudian data lama diisi bertahap di background, dan di akhir kolom itu diubah menjadi non-nullable
  Akan bagus kalau ada alat yang bisa mengekspresikan perubahan prosedural seperti ini secara deklaratif dan bisa direview·dites bersama kode
  Saat ini kebanyakan ditangani dengan skrip sementara dan instruksi deployment manual

  • Saya biasanya menulis migrasi skema sendiri, tetapi kebanyakan memakai grate
    Pengaturannya sederhana di lingkungan development, dan ada contoh seperti FastEndpoints-SqlJobQueues

• Alat ini benar-benar keren
  Berkat ini saya jadi bisa menghentikan proyek hobi saya yang tadinya ingin membuat hal serupa
  Sebagai gantinya saya akan memulai proyek baru yang menangani masalah lain yang sudah diselesaikan 100 kali — misalnya alat sederhana yang memantau log systemd dan mengirim error lewat email

• Menyenangkan melihat ini bukan sekadar migration manager lain, melainkan alat kecil yang berguna
  Rasanya seperti melengkapi kelemahan SQL dengan baik. Saya juga jadi berpikir akan bagus kalau SQL lebih deklaratif seperti Spanner DDL
  Di Postgres, saya berusaha menjaga skrip skema tetap idempotent. Mulai dengan CREATE TABLE IF NOT EXISTS, lalu menaruh ALTER terpisah saat menambahkan kolom baru
  Namun lama-kelamaan skrip menjadi rumit, dan ketika sudah stabil saya merapikan pernyataan ALTER
  Jika suatu saat perlu me-restore backup lama, alat seperti ini tampaknya bisa dengan cepat menyamakan kompatibilitas

• Saya penasaran bagaimana perbandingannya dengan Entity Framework atau sqitch/liquibase
  Saya paham pendekatan deklaratif, tetapi di DB production berskala besar migrasi tidak sesederhana sekadar deklaratif
  Pengelola skema yang ideal harus memahami biaya query dan strategi meminimalkan downtime
  Menambahkan kolom atau mengubah indeks bisa memicu full table scan

  • Masalah yang lebih besar adalah data itu sendiri bisa menjadi bagian dari migrasi
    Misalnya jika Fullname dipecah menjadi FirstName dan LastName, diff sederhana hanya merepresentasikan setengahnya
    Di EF Core, metode Up/Down menangani transformasi yang reversibel
    Saya penasaran bagaimana transformasi data ditangani tanpa konsep seperti ini

• Kami membuat alat transformasi berbasis XML sendiri
  XML lebih mudah diparse daripada SQL, jadi kami membandingkan skema yang didefinisikan di XML dengan DB lalu hanya menerapkan perubahan yang diperlukan
  Kami menggunakan Sybase SQLAnywhere, dan ketika materialized view terlibat ada kerumitan karena view dan indeks harus dibuat ulang saat menambah atau menghapus kolom
  Karena itu kami menambahkan pengaman agar penghapusan kolom hanya diizinkan secara eksplisit, dan perubahan tipe pun hanya dilakukan jika aman
  Ini membuat migrasi menjadi sangat sederhana di ratusan lingkungan instalasi on-premise
  Cukup ubah XML lalu alat akan menanganinya sendiri, dan fitur bisa ditambahkan saat dibutuhkan

• Di SQLite, penanganan penghapusan kolom kurang bagus
  DROP COLUMN baru ditambahkan di versi yang relatif baru, tetapi di sebagian besar perangkat masih belum didukung
  Di contoh, saya menambahkan x integer not null lalu mencoba DROP, tetapi hanya muncul pesan “-- Skipped”
  Cara standar adalah membuat tabel sementara, menyalin data, lalu menggantinya, tetapi alat ini tidak mengotomatisasi itu
  Jika constraint ikut terlibat, ini area yang mudah menimbulkan kesalahan, jadi cukup disayangkan
  Pada akhirnya, kalau hanya menangani pekerjaan yang mudah, rasanya lebih baik dilakukan manual

• Alat ini tampaknya hanya berguna untuk database kosong
  Ini tidak bisa menangani migrasi data, dan pada tabel dengan data nyata juga tidak bisa dipakai untuk kasus seperti mengubah kolom JSONB menjadi bentuk terstruktur atau saat reverse migration setelah menghapus kolom lalu menghasilkan ADD COLUMN … NOT NULL