In my current project we used to maintain a good number of rails migration scripts until, one guest developer stepped into the team for a short while and shared his knowledge on consolidating Rails DB migrations which I intend to blog about in this post.
So what is consolidating DB migrations all about? So if you have the DB migrations say, 1_aaa.rb, 2_bbb.rb and 3_ccc.rb that has gone into your production release 1.00, post your successful release (or a day or two after that), you can consolidate the scripts to something, say 3_consolidated_migrations.rb, wherein this new script essentially borrows the id (here it's 3) from the last run migration in production release and the contents being the same as schema.rb
So what are the implications of this? Well you need to keep in mind of the following:
- Without this approach being adopted, we can just about run the DB migrations on DB dump irrespective of its snapshot date. To put it other way, adopting this practice implies that you'll necessarily have to get the snapshot of Production DB that is no behind the release - say, if you have made released v3, then the DB snapshot has to be after release v3 is made successful.
- If you had written data migration scripts, say from a table1.column1 to table2.column2, these would be lost. However, is there a point of having them in the scripts beyond successful release to production? In most of the occassions, your answer will be NO. However, if you have a compelling reason to have such data migration scripts in Rails DB migrations, then you may not choose DB consolidation.
- This one is very important to reckon with. If your DB migrations have scripts related to DB constraints - primary and foreign key, then all these will be lost with DB Consolidation, as we don't have rails api that is DB agnostic. As a work around you may maintain these scripts in separate DB specific .sql file - something like oracle_db_constraints.sql. In our project, whenever we had to introduce this kind of constraints, we had it both in DB migrations script specific for that release and add the same to the list of SQL(s) in the .sql file(s) that we maintain separately.
- Some Rails team adopt the practice of including scripts for seed data insertion, in the db migrations scripts. This will be lost with DB consolidation, which in my opinion is a good one because it then forces the team to have a seperate file for this purpose (remember 'Seperation of Concerns' here). The other approach is to exclude this specific migration file from DB consolidation code based on this file pattern, which in my humble opinion is not bad thing.