4 ms·
Exactly this. If your db changes are compatible in both directions then you are safe. It's not hard to achieve. Just make sure new columns have default values a
by kyriakos 7y ago
Exactly this. If your db changes are compatible in both directions then you are safe. It's not hard to achieve. Just make sure new columns have default values and your orm can deal with extra undefined columns and don't drop anything during migrations.
- seanwilson 7y agoWhen do you drop the old e.g. columns and tables that are no longer in use though? You schedule it for say a week later when you're sure you won't need to roll back that far?
- matwood 7y agoCorrect. We 'mark' no longer used database objects for removal at some future date. And mark is really just add a ticket to be completed in the future.
- mooreds 7y agoHow long does it stick around before final removal, typically?
- matwood 7y agoDepends. Table removals are usually quicker because they have zero system impact once all the references in code have been removed. Column removals can require planning depending on the size of the table and if indexes will have to be changed.
- seanwilson 7y agoDo you have a method to rollback database object removals if they cause problems?
- jcampbell1 7y agoAssuming one step per day to rename a column: create new column, update code to write to new and old, update code to read from new, update code only write to new, rename old to something like xxx_del_pending, delete old column. This process lets you validate and rollback/recover if needed.
- seanwilson 7y agoIs there a quicker but still fairly safe alternative to this? If you're working solo for example, this doesn't sound practical.
- matwood 7y agoI'll answer both your questions here. Yes, we can rollback a db change using migrates but usually a true rollback requires a restore since data will be lost. In general what I have found is that database changes are unique to your situation. When an app is small it's fine for them to automatically run with the code commits. The system I deal with now has some very large tables, and running database migrations often requires planning. A column addition might be added weeks before the code is written to use the new column. It's just the nature of dealing with large tables. Working solo, typically also means smaller, so there is a lot more leeway. I would do whatever works for you, and realize it's a good thing if you ever large enough to need to address other problems.