.. index:: single: Managing Migrations Managing Migrations =================== Now that we have a new migration class present, lets run the status task to see if it is there: .. code-block:: bash $ ./doctrine migrations:status == Configuration >> Name: Doctrine Sandbox Migrations >> Database Driver: pdo_mysql >> Database Name: testdb >> Configuration Source: /Users/jwage/Sites/doctrine2git/tools/sandbox/migrations.xml >> Version Table Name: doctrine_migration_versions >> Migrations Namespace: DoctrineMigrations >> Migrations Directory: /Users/jwage/Sites/doctrine2git/tools/sandbox/DoctrineMigrations >> Current Version: 2010-04-16 13:04:22 (20100416130422) >> Latest Version: 2010-04-16 13:04:22 (20100416130422) >> Executed Migrations: 0 >> Available Migrations: 1 >> New Migrations: 1 == Migration Versions >> 2010-04-16 13:04:01 (20100416130401) not migrated As you can see we have a new version present and it is ready to be executed. The problem is it does not have anything in it so nothing would be executed! Let's add some code to it and add a new table: .. code-block:: php namespace DoctrineMigrations; use Doctrine\DBAL\Migrations\AbstractMigration, Doctrine\DBAL\Schema\Schema; class Version20100416130401 extends AbstractMigration { public function up(Schema $schema) { $table = $schema->createTable('users'); $table->addColumn('username', 'string'); $table->addColumn('password', 'string'); } public function down(Schema $schema) { $schema->dropTable('users'); } } Now we are ready to give it a test! First lets just do a dry-run to make sure it produces the SQL we expect: .. code-block:: bash $ ./doctrine migrations:migrate --dry-run Are you sure you wish to continue? y Executing dry run of migration up to 20100416130452 from 0 >> migrating 20100416130452 -> CREATE TABLE users (username VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL) ENGINE = InnoDB Everything looks good so we can remove the *--dry-run* option and actually execute the migration: .. code-block:: bash $ ./doctrine migrations:migrate Are you sure you wish to continue? y Migrating up to 20100416130452 from 0 >> migrating 20100416130452 -> CREATE TABLE users (username VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL) ENGINE = InnoDB >> migrated Alternately, if you wish to run the migrations in an unattended mode, we can add the *--no--interaction* option and then execute the migrations without any extra prompting from Doctrine. .. code-block:: bash $ ./doctrine migrations:migrate --no-interaction Migrating up to 20100416130452 from 0 >> migrating 20100416130452 -> CREATE TABLE users (username VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL) ENGINE = InnoDB >> migrated By checking the status again after using either method you will see everything is updated: .. code-block:: bash $ ./doctrine migrations:status == Configuration >> Name: Doctrine Sandbox Migrations >> Database Driver: pdo_mysql >> Database Name: testdb >> Configuration Source: /Users/jwage/Sites/doctrine2git/tools/sandbox/migrations.xml >> Version Table Name: doctrine_migration_versions >> Migrations Namespace: DoctrineMigrations >> Migrations Directory: /Users/jwage/Sites/doctrine2git/tools/sandbox/DoctrineMigrations >> Current Version: 2010-04-16 13:04:52 (20100416130452) >> Latest Version: 2010-04-16 13:04:52 (20100416130452) >> Executed Migrations: 1 >> Available Migrations: 1 >> New Migrations: 0 == Migration Versions >> 2010-04-16 13:04:01 (20100416130452) migrated Reverting Migrations -------------------- You maybe noticed in the last example that we defined a *down()* method which drops the users table that we created. This method allows us to easily revert changes the schema has been migrated to. The *migrate* command takes a *version* argument which you can use to roll back your schema to a specific version of your migrations: .. code-block:: bash $ ./doctrine migrations:migrate first Are you sure you wish to continue? y Migrating down to 0 from 20100416130422 -- reverting 20100416130422 -> DROP TABLE addresses -- reverted -- reverting 20100416130401 -> DROP TABLE users -- reverted Now our database is back to where we originally started. Give it a check with the status command: .. code-block:: bash $ ./doctrine migrations:status == Configuration >> Name: Doctrine Sandbox Migrations >> Database Driver: pdo_mysql >> Database Name: testdb >> Configuration Source: /Users/jwage/Sites/doctrine2git/tools/sandbox/migrations.xml >> Version Table Name: doctrine_migration_versions >> Migrations Namespace: DoctrineMigrations >> Migrations Directory: /Users/jwage/Sites/doctrine2git/tools/sandbox/DoctrineMigrations >> Current Version: 0 >> Latest Version: 2010-04-16 13:04:22 (20100416130422) >> Executed Migrations: 0 >> Available Migrations: 2 >> New Migrations: 2 == Migration Versions >> 2010-04-16 13:04:01 (20100416130401) not migrated >> 2010-04-16 13:04:22 (20100416130422) not migrated Aliases ------- There are some shortcut for convenience (first, prev, next, latest). So that you don't have to know the name of the migration. You can just call .. code-block:: bash $ ./doctrine migrations:migrate prev Writing Migration SQL Files --------------------------- You can optionally choose to not execute a migration directly on a database and instead output all the SQL statements to a file. This is possible by using the *--write-sql* option of the *migrate* command: .. code-block:: bash $ ./doctrine migrations:migrate --write-sql Executing dry run of migration up to 20100416130422 from 0 >> migrating 20100416130401 -> CREATE TABLE users (username VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL) ENGINE = InnoDB >> migrating 20100416130422 -> CREATE TABLE addresses (id INT NOT NULL, street VARCHAR(255) NOT NULL, PRIMARY KEY(id)) ENGINE = InnoDB Writing migration file to "/path/to/sandbox/doctrine_migration_20100416130405.sql" Now if you have a look at the *doctrine_migration_20100416130405.sql* file you will see the would be executed SQL outputted in a nice format: .. code-block:: bash # Doctrine Migration File Generated on 2010-04-16 13:04:05 # Migrating from 0 to 20100416130422 # Version 20100416130401 CREATE TABLE users (username VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL) ENGINE = InnoDB; # Version 20100416130422 CREATE TABLE addresses (id INT NOT NULL, street VARCHAR(255) NOT NULL, PRIMARY KEY(id)) ENGINE = InnoDB; .. _managing-versions-table: Managing the Version Table -------------------------- Sometimes you may need to manually change something in the database table which manages the versions for some migrations. For this you can use the version task. You can easily add a version like this: .. code-block:: bash $ ./doctrine migrations:version YYYYMMDDHHMMSS --add Or you can delete that version: .. code-block:: bash $ ./doctrine migrations:version YYYYMMDDHHMMSS --delete The command does not execute any migrations code, it simply adds the specified version to the database.