Hi,<div><br></div><div>In one of my current projects, the implementation of one of the models is changing a reasonable amount. There will be a batch of new fields and a couple that are no longer required.</div><div><br></div>
<div>What is the best practice for writing migrations that remove columns from tables? I'm thinking specifically of providing the ability to rollback the changes. Should I ignore this and just write an "up" migration to delete the columns? Should I create a duplicate table at the point of the migration to keep a history of the data in those columns? Should I leave them in the database to fester while removing references to them from the code?<br clear="all">
<div><br></div><div>The API docs say:</div><div><div>"Some transformations are destructive in a manner that cannot be reversed. Migrations of that kind should raise an ActiveRecord::IrreversibleMigration exception in their down method."<br>
</div><div><br></div><div>This seems to go along with my first option but seems unsatisfactory for a production app.</div><div><br></div><div>This covers some nice options (like backing up to a file): <a href="http://stackoverflow.com/a/621363/264376">http://stackoverflow.com/a/621363/264376</a> but I'm interested in what people on here think.</div>
<div><br></div><div><br></div></div><div>Cheers<br></div><div>Ian</div><div><br></div><div><br></div>-- <br>







<br>Ian Kynnersley<br><a href="http://iankynnersley.co.uk" target="_blank">http://iankynnersley.co.uk</a> | +44 (0) 7973 420 829 | <a href="http://twitter.com/kpopper" target="_blank">http://twitter.com/kpopper</a><br>
</div>