OurBigBook
Since sequelize migrations are so hard to get right, it is fundamental to test them.
One way to do it is with our web/bin/test-migration script:
For PostgresQL:
Note that Sequelize SQLite migrations are basically worthless and often incorrectly fail due to foreign key constraints: stackoverflow.com/questions/62667269/sequelize-js-how-do-we-change-column-type-in-migration/70486686#70486686 so you might not care much about making them pass and focus only PostgreSQL.
cd web
bin/test-migration -u1 -a3bin/pg bin/test-migration -u1 -a3The
test-migration script:- does a git checkout out to the previous commit
- regenerates the database
- checks out to master
- and then does the migration
The arguments of
test-migration are fowarded to web/bin/generate-demo-data.js from demo data, -u1 -a5 would produce a small ammount of data, suitable for quick iteration tests.Towards the end of that script, we can see lines of type:
Those are important diffs you might want to look at every time:Therefore, you really want the
+ diff -u tmp.old.sqlite3.sort.sql tmp.new-clean.sqlite3.sort.sql
+ diff -u tmp.new-clean.sqlite3.sort.sql tmp.new-migration.sqlite3.sort.sqltmp.old.sqlite3.sort.sql: old schema before migration, but with lines sorted alphabeticallytmp.new-clean.sqlite3.sort.sql: new schema achieved by dropping the database and re creating at oncetmp.new-migration.sqlite3.sort.sql: new schema achieved migrating from the old state
diff tmp.old.sqlite3.schema tmp.new-clean.sqlite3.schema to be empty. For sqlite3 we actually check that and give an error if they differ, but for PostgreSQL it is a bit harder due to the multiline statements, so just inspect the diffs manually.