5 ms·
One of the practical applications of this concept I've found is that I try to write idempotent database migrations (so rerunning the migration, which is a commo
by pmarreck 8y ago
One of the practical applications of this concept I've found is that I try to write idempotent database migrations (so rerunning the migration, which is a common necessity while you're developing it, but is also useful if problems occur, won't error).
So in essence both the "up" and the "down" migrations are idempotent and warn if they are not (and why).
- jackthetab 8y agoHow do you do it without throwing an error? My philosophy has been to ignore the error if it's a re-application of the migration because the migration _is_ idempotent. So ALTER TABLE foo ADD COLUMN bar INT either succeeds (because there is no bar column) or it fails (because there is a bar column) with no harm done.
- joombaga 8y agoThis would work if you're just ignoring that specific error, but it's better to guard for idempotence. Only apply that ALTER if COLUMN bar doesn't already exist.
- flukus 8y agoDatabase migrations are inherently stateful so I'm not a fan of indompodence here, it can leave the schema in some arbitrary states. I much prefer tools like flyway (https://flywaydb.org/ https://flywaydb.org/) that are more deterministic, each migration will only be run once so you're going from known state to known state.
- pmarreck 8y agoI've had situations where a migration that ran locally just fine, failed in staging and/or production (config-level stuff running into hosted DB access rights, etc.). Those situations are a mess to untangle without idempotent migrations. Also, minor niggle but Flyway isn't database-agnostic, you'd have to use the SQL of whatever DB you happen to be using (although if you code in Java I guess you could use ORM commands)