Development

Migrations (diff)

You must first sign up to be able to contribute.

Changes between Version 4 and Version 5 of Migrations

Show
Ignore:
Author:
l2k (IP: 88.65.243.147)
Timestamp:
10/12/07 13:57:18 (10 years ago)
Comment:

removing obsolete content

Legend:

Unmodified
Added
Removed
Modified
  • Migrations

    v4 v5  
    1 = Migrations "light"
     1= Migrations
    22 
    3 == What it is == 
    4  
    5 Migrations are a cool thing that I first saw in [http://www.rubyonrails.org/ RoR]. They allow you to change the database structure between application revisions without losing data, in essence "a system that automates the process of keeping the schema just as flexible as the code basis as soon as your application enters maintanance or production". Have a look at their [http://media.rubyonrails.org/video/migrations.mov screencast] to see what it is all about. 
    6  
    7 I created some "migrations light" code for one of my projects. It doesn't do RDBMS-abstraction. So you'll have to manually write SQL code. It currently works quite alright for me, though. 
    8 I think something more general is planned for [http://propel.phpdb.org/trac/wiki/Development/Roadmap Propel 2.0]. 
    9  
    10 The posted batch files contain hard a hard coded {{{SF_APP}}} constant. Error handling isn't perfect either. 
    11 The whole thing will be made into a symfony task and packaged as a plugin Real Soon Now™". 
    12  
    13 == How to get it running == 
    14  
    15  1. Put {{{generate-migration.php}}} and {{{migrate.php}}} in your batch dir. You may need to manually adjust the {{{SF_APP}}} constant. 
    16  1. Create a {{{batch/migrations}}} directory. This is where the concrete migrations are stored. (These would actually fit better in the data dir I guess...) 
    17  1. Put {{{sfMigration.class.php}}} and {{{sfMigrator.class.php}}} in your lib dir so they can be autoloaded. 
    18  
    19 == How to use == 
    20  
    21 === step one -- create migration === 
    22 Run {{{generate-migration.php name_of_migration}}}. A new migration class stub will be generated and put into the migrations dir. 
    23  
    24 Then put code into the {{{up()}}} and {{{down()}}} methods.  
    25 The {{{up()}}} code should bring the DB structure to the new version. The {{{down()}}} method should revert what was done in {{{up()}}}.  
    26 To do that you can use the parent class' (sfMigration) methods, e.g. {{{executeSQL()}}}. 
    27 See {{{001_example.php}}}. 
    28  
    29 === step two -- run the migration === 
    30 To actually update the database you have to run {{{batch/migrate.php}}}. That will execute all the migrations from the current DB version up to the latest existing migration. (A automatically created table "schema_info" saves the current DB version in the DB itself.) 
    31 To upgrade or downgrade to a specific DB version call the migrate script with the version as a parameter, e.g. {{{php batch/migrate.php 42}}} 
    32  
    33 You'll have to run that script on your production server after every release that contains DB structure changes. (So put a call to migrate.php in your upgrade script if you have one. There's no harm done by calling migrate.php even if no migrations have been added. It just won't do anything.) 
    34  
    35 == Changelog == 
    36  
    37 === 2007-09-07 === 
    38  
    39 I just uploaded updated versions of {{{sfMigrator}}} and {{{sfMigration}}}. 
    40  
    41 The changes basically are: 
    42  * Migrations are now wrapped in transactions (which unfortunately won't work with DDL at least in MySQL). 
    43  * Basic support for fixture loading. This brings some problems as fixture loading uses Propel objects. (You generally should avoid using Propel objects in migrations. They always expect the database to have the latest schema version. That means if you e.g. add a column in a later migration the migration code using Propel objects won't work any more.) 
    44  * Some coding style corrections. 
    45  * A new diag() function in the migration base class to output information to the command line. 
    46  
    47 Fixture loading works like that:[[BR]] 
    48 You add a folder "fixtures" to your migrations directory. In there you 
    49 can put subdirectories called after the migration number, e.g. "042". 
    50 Then, in {{{Migration042::up()}}} you'd write {{{$this->loadFixtures();}}} at some 
    51 point and it will load all the YAML files in the "042" directory. 
     3The information on this page has been superseded by [wiki:sfPropelMigrationsLightPlugin].