For example, they give an example where widget_description is being added which must be not null. But this should be two migrations: 1) adding the column, 2) making it not null. And because these are now split, they can make incremental changes to the app to accommodate these migrations - the first version working when widget_description is nullable and the second, after the data is fully migrated, when it isn't.

(1) If you're using any `select *`, it's important that your ORM ignores unknown columns (e.g. newly added). I've inherited systems that used libraries that behaved like this, and it's awful.