Subscribe to our feed

Symfony Experts

Symfony Experts
If you have an urgent question for a symfony-related issue, this is the place to ask.


Stack Overflow

The old fashioned way


February 23, 2010 – 9:11am symfony 1.0 migrations

I’m working on a plugin for symfony 1.0 and am really enjoying this workflow. Yes, symfony 1.0 is 4 versions old and should not be used for new projects.

With the help of the sfPropelMigrationsLightPlugin plugin, one of my favorites, I have been rapidly making changes to my plugin schema and adding new data to the database over and over again while I mock things up.

Here is the workflow:

1. make changes to the plugin’s schema.yml file, in plugins/myPlugin/config/schema.yml
2. make changes to the plugin’s fixtures file, in plugins/myPlugin/data/fixtures/fixtures.yml
3. rebuild the model
4. rebuild the sql
5. copy the plugin’s sql to the migration sql source file
6. run the migration
7. load the fixtures

This gives me my new schema and populates it with whatever data I have in the fixtures.

Optionally, if I want to go back and make another change, I migrate down a version first, then run through the process above.

The trick is to make your migration run an external SQL file, and to use the plugin’s generated SQL as the source for that migration.

Here is my migration (remember this uses the sfMigrationsLightPlugin):

 * Migrations between versions 033 and 034.
class Migration034 extends sfMigration
   * Migrate up to version 034.
  public function up()
   * Migrate down to version 033.
  public function down()
    $this->executeSQL("SET FOREIGN_KEY_CHECKS = 0;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_import_map`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_profile_history`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_batch_import`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_batch`;");
    $this->executeSQL("DROP TABLE IF EXISTS `dataflow_profile`;");
    $this->executeSQL("SET FOREIGN_KEY_CHECKS = 1;");

Here’s how I run it, once I have completed my new schema.yml and fixtures.yml changes.

# if this is not the first time I'm going through this process, 
# I need to migrate back a step to remove my old plugin tables
./symfony migrate myapp:dev 33  #33 is my previous migration number
>> migrations migrated 1 step(s)
>> migrations current database version: 33
$ ./symfony propel-build-model
cp data/sql/plugins.stDataflowPlugin.lib.model.schema.sql data/migrations/034_stDataflow.sql
./symfony migrate npas:dev 34
>> migrations migrated 1 step(s)
>> migrations current database version: 34
./symfony propel-load-data npas dev plugins/stDataflowPlugin/data/fixtures/fixtures.yml
>> propel    load data from "plugins/stDataf...gin/data/fixtures/fixtures.yml"

It’s nothing novel, but a good example of using the tools to improve the workflow.

Posted by in  Web Development   |  

One Response to symfony 1.0 migrations

  1. Jacob Coby says:

    I’ve taken the sfPropelMigrationsLight plugin and added timestamp versions instead of sequential versions and added migration tracking to allow for out of order sequential migrations, similar to RoR migrations. Works great for teams and when dealing with branches and merges and it’s backwards-compatible with migrations light. I’ll probably be adding some helpers to do common things like adding/removing columns or tables.

    The code is on github: