4 ms·
Author here. Where I've used this in a CI environment, the migration step goes from: - check schema version number, if newer version exists, apply migration fi
by djrobstep 8y ago
Author here. Where I've used this in a CI environment, the migration step goes from:
- check schema version number, if newer version exists, apply migration files
to:
- check schema on this branch matches production schema exactly, if it doesn't, look for (one or more) pending migration files that would bring production to target state, apply those files
So you can still have multiple migration files as needed. The differences:
- no version numbers
- no long migration chain (you can clean up old pending files once they've hit prod)
- migrations are tested directly, and only get applied if a correct outcome will result
- fbonetti 8y agoHow would you handle a situation where the underlying data needs to be transformed? For example, converting a text column to an int column?
- djrobstep 8y agoIn that particular example, migra will detect that change and generate the right `alter column` statement with a `using` clause. It's impossible to handle every case, of course, such as when renames happen or data needs to be moved/inserted. Migration scripts always need reviewing. Tools can get you most of the way there automatically, and help you test, but not all of the way.