Hacker News new | ask | show | jobs
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.