Hacker News new | comments | show | ask | jobs | submit login

I tend to think in terms of "augmentations" instead of migrations. Backwards-compatible data changes are way to go. Adding tables/columns is better than removing tables/columns.

My app, on startup, ensures that it has all of the tables (with all of the columns) and any seed data that it may need (by issuing ADD TABLE and/or ALTER TABLE). This allows me to simply roll out new (tiny, incremental) database changes and code and be sure that it works.

This also makes testing easier, in that my integration tests can start with a new database from scratch, build what needs to be built, run the tests that talk to the database, and then remove the database once it has finished.

If you must make non-backwards compatible changes (renames, whatever), I would suggest doing them one at a time.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact