3 ms·
Ultimately, I don't think migrations are really that useful in the first place. When you have a schema that's actually being changed often, you're in developmen
by aston 19y ago
Ultimately, I don't think migrations are really that useful in the first place. When you have a schema that's actually being changed often, you're in development mode, and you can afford to lose data. You can also be smart (yourself) about how you make changes to the tables to avoid data loss.
If you really do have a need for migration-like functionality, you can make a new database for each major departure. However, eventually you're going to have to reconcile the two, so you'll end up doing what you might have previously no matter what.
- cstejerean 19y agoWhere does development mode end and production mode begin? With the Software as a Service model you can release updates to your code on a biweekly basis. That means the code (and potentially the schema) is always changing. While it is certainly possible to be clever and do things by hand this gets difficult to manage when you have a team of developers and multiple development, testing, staging and production environments. At my current job we use an internal tool that does some of the job but most of the time I want to fallback on using plain files for some data storage because subversion will version and merge it appropriately. I was more curious about whether or not others out there are using better solutions.