[frontend] Changes the way we handle migrations

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

[frontend] Changes the way we handle migrations

Evan Rolfe

Hey OBS developers, since PR #2854 we have some changes to the migrations. Essentially all that this
PR did was:

1. Replace migration 001 with the schema dump from OBS 2.5
2. Delete all migrations which were created before OBS 2.5

One thing that the PR does introduce is that now structure.sql contains "USING BTREE" at the end of
indexes. This is fine because BTREE is the default of mysql
indexes anyway. It does, however, mean that
when you update your local branch from master you will need to "reset your database" to the structure.sql
in git. You can do this with these commands:

`rake db:drop db:create db:setup`

The reason why you need to do this is because otherwise you wont be able to generate new migrations
without schema dump deleting the "USING BTREE" references that are currently in structure.sql in git.
To demonstrate the problem on an existing database locally you can run these commands:

git pull origin master
vagrant exec rails g migration AddTestColumnToProjects test_column:string
vagrant exec rake db:migrate
git diff db/structure.sql

And you will see that db/structure.sql has many lines changed.. Note that if you dont want to create
a new migration at the moment then these steps are not required but you may as well get it over with
sooner rather than later.

I'm sorry if this causes any annoyance but there are many benefits from having this change mainly:

1. Running `rake db:migrate` and `rake db:setup` now result in the exact same database
   (no more "check the migrations and structure.sql are the same" cards on trello)
2. If there is any doubt as to what the correct value of structure.sql is then its simple - the
   correct value is what results from running rake db:migrate on an empty database
3. Merging database changes between branches is easier
4. We can now squash migrations if we want to reduce the number of files in db/migrate (i.e. as is
   done in this tutorial: http://naturaily.com/blog/post/how-to-remove-old-database-migrations-in-ruby-on-rails)


Let me know if you have any questions or concerns about this change.


Evan Rolfe
Full Stack Web Developer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755;  https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)