4 ms·
Eh, DB branching is mostly only necessary for testing - locally, in CI or quick rollbacks on a shared dev instance. Or at least I cannot come up with a usecase
by ffsm8 10mo ago
Eh, DB branching is mostly only necessary for testing - locally, in CI or quick rollbacks on a shared dev instance.
Or at least I cannot come up with a usecase for prod.
From that perspective, it feels like it'd be a perfect usecase to embrace the LLM guided development jank
- notKilgoreTrout 10mo agoMostly.. App migrations that may fail and need a rollback have the problem that you may not be allowed to wipe any transactions so you may want to be putting data to a parallel world that didn't migrate.
- parthdesai 10mo ago> App migrations that may fail and need a rollback have the problem that you may not be allowed to wipe any transactions so you may want to be putting data to a parallel world that didn't migrate. This is why migrations are supposed to be backwards compatible
- notKilgoreTrout 10mo agohttps://github.com/flyway/flywaydb.org/blob/gh-pages/documentation/concepts/migrations.md#important-notes https://github.com/flyway/flywaydb.org/blob/gh-pages/documen... You can certainly bet you followed that advice correctly, now what are the odds you could test a what-if like that in sufficient depth?
- deleted 10mo ago[deleted]
- gavinray 10mo ago> Eh, DB branching is mostly only necessary for testing - locally For local DB's, when I break them, I stop the Docker image and wipe the volume mounts, then restart + apply the "migrations" folder (minus whatever new broken migration caused the issue).