CakePHP Migrations


An interesting topic about CakePHP migration support was raised in the CakePHP discussion group recently. Dardo Sordi wrote a compelling and comprehensive argument in favor of not using migrations in favor of CakePHP’s built in Schema tool. He provided an excellent overview of the tool and a suggested workflow for how he currently uses it in his work.

I thought it would be nice to expand on his argument and provide the counter-point for sake completeness that is in favor of migrations. Joel Moss has created a superb tool that adds migration support to CakePHP which he hopes will some day make it into the CakePHP core.

I have reproduced my argument in favor of migrations below:

1. Migrations as “Patches” - Migrations CAN be patches.

Migrations are not patches though. For example, in Joel’s system you can most certainly create a migration supporting a model that is complete. In many cases models won’t need tweaks, but in some cases, particularly in multi-developer environments, having the ability to create patches is critical.

2. Migrations are incomplete - Migrations CAN be incomplete, but when migrations are run in sequence they are as complete as a Schema.

Git allows you to keep a local copy of the SCM in which you can create your own revisions and then sync it later. Many developers, in fact I would suggest most, do not use Git yet. I would argue that the majority of folks are on some flavor of SVN or CVS. In these cases there is no local revision only the revision you have to commit.

Let me propose the counter-argument to why migrations are superior to Schema. I think this is a debate that could be endless, but in terms of commonly accepted practice in interative agile development there are many more proponents of the migration model than the Schema model.

1. Migrations are iterative.

When you’re developing it is useful to back out model changes if they do not work. With Schema, you’re working directly with the SQL which is not necessarily database agnostic. Once you back out that change you have no way to return to any other state unless you check out a file from your SCM.

In this way your iterative development model is supported step-by-step with your migrations. You can track and move your application to any state you need without needing to check out full blown schemas.

2. Migrations are multi-developer friendly.

Migrations are iterative, so one developer’s work will not overwrite another developer’s work. In the Schema model you’ve got multiple developers committing their latest schema and relying on the SCM to stitch the changes into the proper order. Migrations also quickly allow developers to review specific database changes without needing to review a single large file and finding the changes.

3. Migrations allow easier rollout

Let’s say you need to roll out a single feature. In a migration you just rollout that migration on your production environment with your code deploy and you’re set. In a Schema environemnt you need to backup your database, rollout the new schema, restore the data and you’re good to go. While database backups should be a part of any production environment rollout, having to backup / restore for even minor database changes can be tiresome particularly when you’re just trying to fix a single bug in a production application.

4. Migrations have a reputable body or work behind them:

http://www.oracle.com/technology/pub/articles/kern-rails-migrations.html
http://www.oreillynet.com/pub/a/ruby/2007/05/17/cookin-with-ruby-on-rails—may.html
http://www.ibm.com/developerworks/web/library/j-cb08156.html

While I think there are many ways to handle database schemas, the migration model is currently the best of breed model on the market. If multi-developer iterative design is the new model for application development then there is no reason to avoid migrations. Joel’s work has been ongoing and his latest efforts are most definitely worth a look. His migration model should make it into Cake 2.0 if not sooner because of the value it adds to the core set of console tools available with cakePHP.

Previous Articles

Symfony 1.1 Installation OS X Leopard


Passenger Debuts!


CakePHP 1.2 File Upload


Installing CakePHP on OS X Leopard 10.5.1


Content Filtering vs. Authentic Digital Experiences


Milton Waddams & The Red Stapler


Managing Permissions in dotProject


Symfony Tutorial: sfGuardPlugin & Profiles (Part 1)


Sourcecode Test


Welcome to KeithMedlin.com

Thank you for taking the time to visit my blog! Take a second to peek around and check out some of my previous posts!