Fix migrations

[eugenk]

Fix migrations by

• Putting all data-consistency-migrations, which need to be run on ontohub.org and staging.ontohub.org, into rake tasks. Also create a list of rake tasks which need to be run on deploy (containing rake task and the corresponding date/timestamp).
• Squashing all migrations, that are already on ontohub.org, into one migration.

[eugenk]

As for the data migration rake tasks:
Why don't we do it similar to regular migrations? Each file's name is prefixed with the date/time and we store the date/time of the last executed data migrating task somewhere. This way, we would have an automated way to determine which tasks need to be run the next time. Those tasks would be independent of the regular migrations and would need to be changed whenever the used code (e.g. models) changes as well.

[eugenk]

Well, this is basically what the gem data-migrate does. What were the arguments against this approach?

The main problem is

1. Data migrations are written
2. Models change/get removed
3. Old data migrations are not working any more

right?

When we change the data migrations (not the schema migrations!) alongside changing the models, we should not have this problem any more. And data-migrate can take a lot of work off our shoulders because it takes care of which data migrations have been executed already. Futher, the data migrations won't be executed automatically by rake db:migrate. We would have to do this manually with rake data:migrate or rake db:migrate:with_data.

[0robustus1]

Data migrations can take a lot of time, it would be nice to schedule them when we want to (or to run them in background). Would this be possible/feasible with your approach?

[eugenk]

If we can call Sidekiq, yes. I will evaluate this tomorrow.

[eugenk]

Oh and we can always call nohup rake data:migrate & to run it in the background and not abort when we close the ssh connection.