|
|
|
|
|
by GordonS
1888 days ago
|
|
Not the OP, but the way I handle this to to ensure that all migrations are backwards compatible - the current and new versions of the app/API/service must be able to run with the old and new database. This requires a little discipline, but if you follow a few simple rules it's not really that arduous: - when adding a new column, it must have a default value set, or be nullable
- don't drop any columns
- don't rename any columns
Now, for those last 2, what I really mean is "don't do it in a single release" - if you want to make destructive changes, do it over the course of 2 releases. - release 1: remove dependencies on the column from the app/API/service
- release 2: performs the database migration with destructive changes
It probably sounds more difficult than it actually is :) In reality, I don't make destructive changes that often though. |
|