CODEWITHSUNDEEP
ruby-on-railsruby
stephenmurdoch
stephenmurdoch

Reputation: 34603

Irreversible migrations versus brand new migrations?

Our site went into beta a while ago, and now that we have a bunch of production users we realise that we made some big mistakes regarding the initial schema and feel that we now need to modify the structure of our db.

This will result in us writing a bunch of irreversible migrations. Rather than do this, it's been suggested that we could drop our db entirely, destroy all our existing migrations, and then rewrite them from scratch avoiding the mistakes we made first time round.

I have a few questions:

1) does anyone actually do that in real life? 2) what are our options for retaining our data? IS TAPS still the way to go? 3) Or should we just write the irreversible migrations and forget about dropping the db?

This question deals with this somewhat, I guess.

Upvotes: 0

Views: 52

Answers (1)

Simone Carletti
Simone Carletti

Reputation: 176352

An irreversible migration is nothing scary. There may be cases where a migration cannot be reversed.

My suggestion is to not drop the database but change it with small steps.

Start with creating a parallel model for your users or change the existing one with the requires fields. Create one, at least two migrations and deploy making sure that your current application still works as expected.

Then create another batch of migrations and deploy.

It may take 5, 10 or even 20 iterations to change all the structure in the way you want, but you will not go with the process of dropping the db, taking the application offline and importing the entire db later on.

Upvotes: 3

Related Questions