6 ms·
a lot of time writing down migrations? why was it so hard? I use https://fluentmigrator.github.io/ https://fluentmigrator.github.io/ and also used dbup.. I
by keithnz 7y ago
a lot of time writing down migrations? why was it so hard?
I use https://fluentmigrator.github.io/ https://fluentmigrator.github.io/ and also used dbup..
I generally like the up/down better, and both the up and down is remarkably trivial to write generally, the downs are useful during development you might change your mind about the DB structure. Never used a down in production.
- theclaw 7y agoWe used to do this but found it was error prone since the down migrations would have bugs and wouldn’t always catch everything. We have dedicated SQL devs that write the migrations by hand and so moving to generated code is a slow and painful process. We now encourage developers working on the DB to thrash out their design in a local SQL Server Express instance before baking their changes into a migration script that will be automatically run into our dev env by octopus. If the scripts don’t run or the tests against the temporary DB fail during build then they never get to our shared dev DB.
- keithnz 7y agowe never have problems with it. It's all local, we don't have a shared dev DB, I think that's asking for trouble. We have test stacks, and a production stack. Those DBS are TBs in size. Locally we have a conditioned DB thats much smaller. The rule is locally, you only change your DB via migration.