We're switching from ragtime and something that surprised us, as postgresql users, was the auto rollback when the up migration failed. Looking at #111 it seems like maybe that's the world mysql users live in. For my team, that seems very dangerous, since our rollbacks are written assuming the migration was committed.
Consider this migration:
up:
update foo set bar = 'prefix-' || bar;
down:
update foo set bar = substring(bar, 8);
Anyways, we've introduced a config :tx-handles-ddl flag that skips the automatic down that occurs on exception -- basically allows ignoring #111.
We're switching from ragtime and something that surprised us, as postgresql users, was the auto rollback when the up migration failed. Looking at #111 it seems like maybe that's the world mysql users live in. For my team, that seems very dangerous, since our rollbacks are written assuming the migration was committed.
Consider this migration:
up:
update foo set bar = 'prefix-' || bar;
down:
update foo set bar = substring(bar, 8);
Anyways, we've introduced a config
:tx-handles-ddl
flag that skips the automatic down that occurs on exception -- basically allows ignoring #111.