doctrine / migrations

Doctrine Database Migrations Library

Doctrine Migrations

Documentation

All available documentation can be found here.

migrations's Issues

Command to add all migrations to the versions table would be helpful

When you deploy an existing application which has migrations to a new test server, for example, then its database has the current schema definition and does not have to get the existing migrations applied. For this, you need to run the command

./doctrine migrations:version YYYYMMDDHHMMSS --add

for all existing migrations to tell the application that they do not have to be applied, if I understood things correctly. A small command extension like

./doctrine migrations:version --all --add

would be extremely helpful in this case. Would this seem possible? An alternative would be to integrate the migrations with the schema:create command, but that might be more difficult and maybe not even desirable.

Thanks so much for considering.

Regards, mg

Migrations diff command, creates a new file if you do not find differences

Execute the command migrations diff in the case where is no changes creates a new file

./app/console doctrine:migrations:diff

Generated new migration class to "/home/songoq/project/app/DoctrineMigrations/Version20110803142018.php" from schema differences.

cat /home/songoq/project/app/DoctrineMigrations/Version20110803142018.php

...
...
... 

class Version20110803142018 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        // this up() migration is autogenerated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");

    }

    public function down(Schema $schema)
    {
        // this down() migration is autogenerated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");

    }
}

Allow to change config file path

Hi,

I am not sure if this feature is already implemented. I couldn't find it. I am setting up doctrine migrations on top of silex and I have to pass --configuration argument everytime I run it at commandline or I have to change working dir to the same as migration configuration file.

php console.php migrations:status --configuration=config/migrations.yml
or
chdir(DIR.'/config');

It would be nice to allow configure it before running commandline.

LIMIT 1 is not supported by SqlSrv

In Configuration::getCurrentVersion()
https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Configuration/Configuration.php#L363
used 'LIMIT 1' in SQL clause. This construction is not supported by SqlSrv.

Always drop table Migration_version

Hello,

Config : symfony 2.2, os x 10.8.3, PHP 5.4.4, Apache 2, Database ; oracle OSI 8.

When I type the doctrine:migrations:diff, I always have this line generated :

public function up(Schema $schema)
    {
        // this up() migration is autogenerated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "oracle");

        $this->addSql("DROP TABLE MIGRATION_VERSIONS");
    }

So the big problem is : always when I create a DIFF migration file, he drop the table migration and re-create it after with the new migration value. When I get my third migration file he forgot that he already have execute the first one (who have been drop by the second one) and generate a lot of error.

So why he always generate this drop table ?!

Thanks to help me !

Doctrine\ORM\Mapping\Column class dont have 'default' property

it is expected to be here as it could be used in doctrine migration.
Other parts already implemented: in Doctrine\ORM\Tools\ShemaTool::_gatherColumn it is fetch from metadata and in Doctrine\DBAL\Schema\Comparator::diffColumn it is already checking if it is the same

Issue moved from: doctrine/DoctrineMigrationsBundle#35

Formatter exceptions with HTML in SQL queries

I created a test case & two solutions here:
http://github.com/ericclemmons/migrations/commits/hotfix%2Fhtml-in-sql-query-output-bug

I believe the bug fix may be better suited in \Symfony\Component\Console\Output\Output. Either that, or have Version.php or the OutputWriter specifically use the Output::OUTPUT_PLAIN or Output::OUTPUT_RAW constant.

2 one to many relationship, doctrine:migration:diff sees only the last one

I noticed that having three entities A, B, C configured as it follows:

1. A-B (1-N) and B-A (N-1)
2. A-C (1-N) and C-A (N-1)

make the "doctrine:migrations:diff" command create only the 2nd relationship, this happens also if you switch the order of them. To obtain the desired two relationship I had to write one first, doctrine:migrations:diff, and then add the other one and do again doctrine:migrations:diff

Here's my symfony2's deps file: http://pastebin.com/kLZ9cXd1

Do you confirm it?

No documentation!

No documentation at http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

Migration status error with SQL Server

After creating the version table at the database, if we issue a migrations:status and the database server is SQL Server, it's appending the LIMIT 1 to the query.

Probably it might be a problem with the DBAL Plataform for SQL Server (pdo_sqlsrv), but I saw at migrations / lib / Doctrine / DBAL / Migrations / Configuration / Configuration.php line 431 that it get this info from the plataform.

migrations:migrate doesn't cross-check all file migration versions with DB entries

the problem arises when multiple developers work with migrations and in one case migrations could be skipped:

1. Developer A creates migration 20120228123443 and runs it against local DB.
2. In the mean time unaware of this migration developer B creates migration 20120228114838 runs it against local DB and pushes it to the central repository.
3. Developer A pulls changes, receives migration 20120228114838, runs doctrine.php migrations:migrate.

The 20120228114838 is skipped because last migration in DB is newer then the one received, and since a full cross-ref with DB is not run, the migration does not get executed.

Space needed in "REFERENCES name (id)" to avoid mysql errors

In generated migrations classes I have to put an space in all:

REFERENCES name(id)

like that:

REFERENCES name (id)

to avoid sql errors when executing

Using mysql Ver 14.12 Distrib 5.0.77

createMigrationTable() makes the version column string instead of integer

In Doctrine\DBAL\Migrations\Configuration\Configuration::createMigrationTable() the version column is specificed as string.

However, the version format is YYYYMMDDHHMMSS and when getCurrentVersion() queries the table it does not convert the values to strings:

$sql = "SELECT version FROM " . $this->migrationsTableName . " WHERE version IN (" . implode(', ', $migratedVersions) . ") ORDER BY version DESC";

Therefore, you are relying on the database to implicitly convert the supplied integers to string. Postgresql in particular doesn't do this, so you get:

ERROR:  operator does not exist: character varying = bigint
LINE 1: ...c_owner.doctrine_migration_versions WHERE version IN (201204...

Therefore, I think we need to create the table such that the version column has format integer or bigint, or change getCurrentVersion() so that it quotes the values in the implode function.

I'm happy to prepare a PR if there is a consensus on which approach is preferred.

URL on github page points to non-existing project page

This is the correct project page: http://www.doctrine-project.org/projects/migrations.html (corrected)
Old URL: http://www.doctrine-project.org/extension/migrations

$table->renameColumn() drops the column

In one of my migration scripts I needed to rename the column and tried to use the renameColumn() method.

Unfortunately, this did not worked - it only dropped it.

Looking at the code of the method, there's definitely something missing:

    /**
     * Rename Column
     *
     * @param string $oldColumnName
     * @param string $newColumnName
     * @return Table
     */
    public function renameColumn($oldColumnName, $newColumnName)
    {
        $column = $this->getColumn($oldColumnName);
        $this->dropColumn($oldColumnName);

        $column->_setName($newColumnName);
        return $this;
    }

"php package.php" Illegal stub error.

PHP Fatal error:  Uncaught exception 'PharException' with message 'illegal stub for phar "/var/www/nolimits/public/modules/migrations/vendor/migrations/build/doctrine-migrations.phar"' in /var/www/nolimits/public/modules/migrations/vendor/migrations/package.php:38
Stack trace:
#0 /var/www/nolimits/public/modules/migrations/vendor/migrations/package.php(38): Phar->setStub('setStub() /var/www/nolimits/public/modules/migrations/vendor/migrations/package.php:38

Running from the latest commit aab5b20 and using PHP 5.3.5

Connection is not rolled back on dry run

In Version the connection is committed even during a dry run.

This isn't an issue for SQL added via addSQL (or through SchemaManager), which are never executed, however, a reference to the connection is protected in AbstractMigration, so it's possible to use the connection to do advanced data manipulation: using a PHP function to modify data, for example. These changes are committed even during a dry run.

It seems that either the $connection in AbstractMigration should be private (a BC break) or the connection should be rolled back.

We use the protected connection once in a while to do complex data manipulation. One could argue that this migration tool should only be used for static SQL, but so far we've found it easiest to pool all DDL, DML and custom transformations in one place.

Updated to for doctrine2 compatibility?

Current, doctrine/migrations uses tasks
\DoctrineExtensions\Migrations\Tools\Cli\Tasks\MigrateTask

The latest version of doctrine/doctrine2 uses "commands" and has switched from using Cli to a HelperSet:
\Doctrine\DBAL\Tools\Console\Command\RunSqlCommand

Is this library (or will this library be) the standard migrations tool for Doctrine2, or are migrations should we just monitor doctrine/doctrine2 for that functionality?

Warning issued when reverting and no migrations available

When reverting to "" (empty string) , The system is supposed to revert every migations which works fine if there are any migration done previously but if there are none, PHP issues a warning :

Warning: array_combine(): Both parameters should have at least 1 element in F:\workspace_php\claronext\vendor\doctrine-migrations\lib\Doctrine\DBAL\Migrations\Configuration\Configuration.php line 470

The line can be found here :

https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Configuration/Configuration.php#L470

It is a strange behaviour of PHP (and undocumented : http://php.net/manual/en/function.array-combine.php ) but as long as it is not fixed in the language, an extra test should do the trick.

PS : I'm using php 5.3.5with zend engine 2.3.0 and xdebug 2.1.0 on windows

Executing inserts/deletions/updates on entities in the database during migrations

Hello, I need to execute some inserts/deletions/updates on entities in the database during migrations. I tried to use the connection field of the migration, like below:

public function up(Schema $schema)
{
$this->_connection->insert('user', array(
'login' => 'admin',
'name' => 'Admin',
'password' => crypt('admin'),
'status' => 1,
));
}

But when executing migrations, it prints the error message "No SQL commands found", unless I add this line:

$this->_version->markMigrated();

So, how am I supposed to perform INSERTS/DELETIONS/UPDATES on data during migration of the database?

Thanks for your help.

PostgreSQL: Down migrations contain drops for indexes that were already dropped automatically

I've encountered a strange behavior while using Migrations with ORM on PostgreSQL. When the diff command generates migration, it adds drops for indexes to down part even if the index is dropped automatically by some of previous queries.
According to PostgreSQL documentation for DROP COLUMN:

Indexes and table constraints involving the column will be automatically dropped as well. You will need to say CASCADE if anything outside the table depends on the column, for example, foreign key references or views.

So when there was a field foo with an index on it, the migration first drops the column and after that, it tries drop the index (which doesn't exist anymore at that time).

The solution (and a workaround) seems to be either to swap these two SQLs so the index is dropped first or to completely skip generating SQLs for dropping indexes which are on some of the columns dropped previously.

Change the URL link to this project on GitHub

This project's Github page (https://github.com/doctrine/migrations) links to the http://www.doctrine-project.org/extension/migrations page which doesn't exist anymore.

Change it to http://www.doctrine-project.org/projects/migrations.html .

Easy but nice :)

Issue with migration dry-runs and ORM

The Symfony manual encourages users to go and fetch the ORM Entity Manager inside postUp functions to go and set up entities/manipulate data (see http://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html#container-aware-migrations).

The problem with this is that it doesn't get along with dry-run operations. The console ends up with an error, as the postUp function actually executes, and the entity manager is oblivious to the fact that it's only pretending to be doing operations.

As far as I could tell, there isn't an exposed way to detect dry runs and therefore skip processing inside your postUp functions.

Either the Doctrine EM needs to be able to detect dry runs and just log what it wanted to do, or we need a way of detecting dry run mode and choosing to skip.

Sequence generation for doctrine ORM and Migrations

I'm getting different results from doctrine ORM and doctrine migrations for creating auto incrementing id columns in oracle.

Migrations is missing the column name in the pattern {dbname}_{column}_seq. It looks like there are two different strategies for generating sequence names between ORM and DBAL/Platform/OraclePlatform.

Creating my entity in PHP annotations like:

/**
 * @Entity
 * @Table(name="types")
 * */
class Type
{

    /**
     * @Id
     * @Column(type="bigint")
     * @GeneratedValue(strategy="AUTO")
     */
    private $id;
}

and running schema-tool:update --dump-sql results in:

CREATE SEQUENCE types_id_seq START WITH 1 MINVALUE 1 INCREMENT BY 1

doing this in doctrine migrations:

public function up(\Doctrine\DBAL\Schema\Schema $schema)
{
  $table = $schema->createTable('types');
  $table->addColumn('id', 'bigint', array('autoincrement' => true));
  $table->setPrimaryKey(array('id'), 'primary');
}

results in:

CREATE SEQUENCE TYPES_SEQ START WITH 1 MINVALUE 1 INCREMENT BY 1

Cannot ask for an older version

I am using Symfonx 2.0.17 and I try to execute php app/console doctrine:migrations:diff

The problem is that this is not working from the last commit : 5dffedd

It should be possible to request an older version and the best idea would be to add a tag for the version which is compatible with Doctrine 2.1

Not all dependencies are resolved by composer (Symfony\Yaml)

I've cloned this repository, then downloaded all the dependencies using update composer command and after I run phpunit this is what I get:

$ phpunit
PHPUnit 3.6.12 by Sebastian Bergmann.

Configuration read from /var/www/doctrine-migrations/phpunit.xml.dist

....PHP Fatal error:  Class 'Symfony\Component\Yaml\Yaml' not found in /var/www/doctrine-migrations/lib/Doctrine/DBAL/Migrations/Configuration/YamlConfiguration.php on line 39
PHP Stack trace:
PHP   1. {main}() /usr/bin/phpunit:0
PHP   2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:46
PHP   3. PHPUnit_TextUI_Command->run() /usr/share/php/PHPUnit/TextUI/Command.php:130
PHP   4. PHPUnit_TextUI_TestRunner->doRun() /usr/share/php/PHPUnit/TextUI/Command.php:192
PHP   5. PHPUnit_Framework_TestSuite->run() /usr/share/php/PHPUnit/TextUI/TestRunner.php:325
PHP   6. PHPUnit_Framework_TestSuite->run() /usr/share/php/PHPUnit/Framework/TestSuite.php:705
PHP   7. PHPUnit_Framework_TestSuite->runTest() /usr/share/php/PHPUnit/Framework/TestSuite.php:745
PHP   8. PHPUnit_Framework_TestCase->run() /usr/share/php/PHPUnit/Framework/TestSuite.php:772
PHP   9. PHPUnit_Framework_TestResult->run() /usr/share/php/PHPUnit/Framework/TestCase.php:751
PHP  10. PHPUnit_Framework_TestCase->runBare() /usr/share/php/PHPUnit/Framework/TestResult.php:649
PHP  11. PHPUnit_Framework_TestCase->runTest() /usr/share/php/PHPUnit/Framework/TestCase.php:804
PHP  12. ReflectionMethod->invokeArgs() /usr/share/php/PHPUnit/Framework/TestCase.php:942
PHP  13. Doctrine\DBAL\Migrations\Tests\Configuration\AbstractConfigurationTest->testMigrationDirectory() /usr/share/php/PHPUnit/Framework/TestCase.php:942
PHP  14. Doctrine\DBAL\Migrations\Tests\Configuration\YamlConfigurationTest->loadConfiguration() /var/www/doctrine-migrations/tests/Doctrine/DBAL/Migrations/Tests/Configuration/AbstractConfigurationTest.php:14
PHP  15. Doctrine\DBAL\Migrations\Configuration\AbstractFileConfiguration->load() /var/www/doctrine-migrations/tests/Doctrine/DBAL/Migrations/Tests/Configuration/YamlConfigurationTest.php:12
PHP  16. Doctrine\DBAL\Migrations\Configuration\YamlConfiguration->doLoad() /var/www/doctrine-migrations/lib/Doctrine/DBAL/Migrations/Configuration/AbstractFileConfiguration.php:65

doctrine:migrations:diff "--filter-expression" option ignored for $toSchema

I'm not really sure is it a bug or just my misunderstanding, but when I'm using diff command like:

doctrine:migrations:diff --filter-expression='~^(?!t_)~'

I expected to see all tables not prefixed with "t_" in generated migration. But prefixed tables are in it. This is because "filter-expression" option is applied only for $fromSchema and ignored for $toSchema, which is generated from entities metadata.

A bit confusing, as for me. :)

May be it'll be better to apply filter for all schemas?
For example like this:

$tool = new SchemaTool($em);

$fromSchema = $conn->getSchemaManager()->createSchema();
$toSchema = $tool->getSchemaFromMetadata($metadata);

if ($filterExpr) {
        $tableNames = $toSchema->getTableNames();
    foreach($tableNames as $tableName){
        $tableName = substr( $tableName, strpos($tableName,'.') + 1);
        if( !preg_match( $filterExpr, $tableName ) ){
            $toSchema->dropTable($tableName);
        }
    }
}

wrong mysql dump generation for foreign keys

Doctrine builds wrong schema for foreign keys in mysql migrations.

My entities:
/**

• @entity
• @table(name="Catalog_Field")
  /
  class Catalog_Model_Field
  {
  /*
  • @var Catalog_Model_FieldGroup
    *
  • @manytoone(targetEntity="Catalog_Model_FieldGroup")
  • @joincolumn(name="groupId", referencedColumnName="id")
    */
    private $group;
    }

/**

• @entity
• @table(name="Catalog_FieldGroup")
  /
  class Catalog_Model_FieldGroup
  {
  /*
  • Identifier.
  • @var integer
    *
  • @id @column(name="id", type="integer")
  • @GeneratedValue(strategy="IDENTITY")
    */
    private $id;
    }

doctrine migrations:migrate in current doctrine version:
up:
ALTER TABLE Catalog_Field ADD CONSTRAINT FOREIGN KEY (groupId) REFERENCES Catalog_FieldGroup(id)
down:
ALTER TABLE Catalog_Field DROP FOREIGN KEY

should be:
up:
ALTER TABLE Catalog_Field ADD CONSTRAINT Catalog_Field_ibfk_2 FOREIGN KEY (groupId) REFERENCES Catalog_FieldGroup(id)
down:
ALTER TABLE Catalog_Field DROP FOREIGN KEY catalog_field_ibfk_2

Indexes and uniqueConstraints has been ignored

I declared my entity with the indexes section, like this:

indexes:
        IDX_ADDRESS_CITY:
            columns: city_id

but, the Diff tools ignore it and give me this code:
$this->addSql("CREATE INDEX IDX_7299B5238BAC62AF ON tb_address (city_id)");

and it should be:
$this->addSql("CREATE INDEX IDX_ADDRESS_CITY ON tb_address (city_id)");

duplicate issue tracking

other doctrine projects do not have the github issue tracker but use doctrine jira. this project has both the github issue tracker as well as issues in jira at http://www.doctrine-project.org/jira/browse/DMIG

Wrong version numbers in DiffCommand

Hi,

i think there's an error in the Doctrine\DBAL\Migrations\Tools\Console\Command\DiffCommand.php on line 89 -> $version = date('YmdHms');

i think this line should be replaced with $version = date('YmdHis'); to get the version files in the correct order

Migrate down

Hello.

On cakephp, there was a great function that allow us to simply migrate from a version n to version n-1.
Migrate down.

Do you think you could implement such a function ?

The nicea thing is taht when you actually test your migration, you can easily go back to the last version without wondering what name it has.

When you have to generate / modify / update few time the migration script to get the right result, it's much easier to test that the new script works fine in both way like that.

Best regards,
Pierre

Newest version fail at detecting if migrations table exists on pgsql

see #94 (comment)

migrations:diff always creates Version file

Using the following command

./doctrine migrations:diff

does always create a version file even if there are no changes to be made to the current schema.

The content of this file is for example

namespace Application\Migrations;

use Doctrine\DBAL\Migrations\AbstractMigration,
    Doctrine\DBAL\Schema\Schema;

/**
 * Auto-generated Migration: Please modify to your need!
 */
class Version20121210110653 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        // this up() migration is autogenerated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");

    }

    public function down(Schema $schema)
    {
        // this down() migration is autogenerated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");

    }
}

In Doctrine\DBAL\Migrations\Tools\Console\Command\DiffCommand there is always the 'abortIf()' line added to the Version-Code.

As we want to use Migrations in a semi automatic build process these 'empty' versions are really annoying.

(Kind of duplicates #41)

Problem with executing INSERT/DELETE/UPDATE during the migration

Hello, I need to execute some inserts/deletions/updates on entities in the database during migrations. I tried to use the connection field of the migration, like below:

public function up(Schema $schema)
{
$this->_connection->insert('user', array(
'login' => 'admin',
'name' => 'Admin',
'password' => crypt('admin'),
'status' => 1,
));
}

But when executing migrations, it prints the error message "No SQL commands found", unless I add this line:

$this->_version->markMigrated();

So, how am I supposed to perform INSERTS/DELETIONS/UPDATES on data during migration of the database?

Thanks for your help.

Prioritise --db-configuration option in AbstractCommand.php

In AbstractCommand::getMigrationConfiguration() the helperset is checked first for the db helper.

It would be more useful if the --db-configuration option is checked first to allow overrides in the working directory with a cli-config.php file.

DB configuration array key not consistent

In Doctrine2 one of the params for the db config is 'username', but in Migrations it is 'user'. Could this be made consistent?

More robust migrations

Hi, guys. I'm trying to perform some migrations to alter my database schema and then normalize data on the new tables.

For example: I want to create new entities based on those that already exist in my database. So, raw SQL is not an option here. Then I'm trying to use the entity manager from container to retrieve entities and create new ones from them.

I got stuck when I need to persist an entity and then gets it to use in another entity relation. The id from the first flushed entity is null. Can it be because the whole migration is executed inside a database transaction?

If it is really occurring by the database transaction, is it possible to make it more flexible in the way we can perform this kind of migration?

I'm not sure if here is the right place for this kind of post... but it could be an improvement for migrations.

Thanks.

Data loss on table renaming.

With the feature $schema->renameTable('old', 'new'); you end up losing your data due to how this function works.

Doctrine creates a new table with the old table definitions and then drops the old table. It fails to migrate the data into the new table. There are two solutions to this problem (1st one preferred):

1. Use the native statement (RENAME TABLE old TO new) Documentation
2. SELECT the old data into the new table.

Thoughts appreciated.

Drop foreign key doesn't work

Hi,

I'm using doctrine migrations along with Symfony 2 and DoctrineMigrationsBundle on a PostgreSQL database. Discovered a strange behaviour of the doctrine:migrations:migrate command when trying to migrate down.

I added a foreign key with this SQL on up():

ALTER TABLE show_instance ADD CONSTRAINT FK_7B5450313F82F4D7 FOREIGN KEY (redbtnCampaign_id) REFERENCES redbtn_campaigns(campaign_id) ON DELETE SET NULL NOT DEFERRABLE INITIALLY IMMEDIATE

On down() the following SQL is used:

ALTER TABLE show_instance DROP CONSTRAINT FK_7B5450313F82F4D7

doctrine:migrations:migrate VERSION (down) fails to drop the foreign key and tells me that:

[PDOException]                                                                   

  SQLSTATE[42704]: Undefined object: 7 ERROR:  constraint "fk_7b5450313f82f4d7" of 
relation "show_instance" does not exist

Although when I look it up in the database, it is there! And executing the exactly same drop command directly on the database works.

I'm using the latest version of doctrine/migrations and the latest version of the symfony/DoctrineMigrationsBundle (on branch 2.0)

Maybe you can help me?

Thanks,
Edi

Documentation link is broken

Documentation link in readme leads to http://www.doctrine-project.org/projects/migrations/2.0/docs/en

But it's 404 page. Not sure where is actual documentation?

Edit: Link in description is broken as well: http://www.doctrine-project.org/extension/migrations

bug with migrations downgrade

I created two simple entities https://github.com/stfalcon/BlogBundle/tree/master/Entity
And generated migrations diff https://github.com/stfalcon/portfolio/blob/master/app/DoctrineMigrations/Version20110520075206.php

Command doctrine:migrations:migrate works fine. But I get error when try downgrade last migration:

Migrating down to 20110520062748 from 20110520075206

  -- reverting 20110520075206

     -> ALTER TABLE blog_posts_tags DROP FOREIGN KEY 
Migration 20110520075206 failed during Execution. Error SQLSTATE[HY000]: General error: 1005 Can't create table 'stfalcon_com_development.#sql-5af_119' (errno: 150)


                                                                                                                
  [PDOException]                                                                                                
  SQLSTATE[HY000]: General error: 1005 Can't create table 'stfalcon_com_development.#sql-5af_119' (errno: 150)  
                                                                                                                

Disabling foreign keys check

Would it be possible to add these before and after diff commands:

SET FOREIGN_KEY_CHECKS=0;

SET FOREIGN_KEY_CHECKS=1;

because when we change primary keys, executing version will return a mysql error on foreign keys integrity.

stable release

Please consider creating a tag for a stable release version.

Fields with a default value are erroneously marked as changed by migrations:diff

When a field has a default value defined by options={"default" = 0}, migrations:diff always marks the field as changed, thus generating a migration with unneeded statements.

How to reproduce

Create an entity as follows:

/**
 * @ORM\Table(name="dummy")
 * @ORM\Entity
 */
class DummyIdentity
{
    /**
     * @ORM\Column(type="integer")
     * @ORM\Id
     */
    private $id;

    /**
     * @ORM\Column(type="integer", options={"default" = 0})
     */
    private $dummy;
}

1. Generate a migration with doctrine:migrations:diff
2. Run the generated migration with doctrine:migrations:migrate
3. Run doctrine:migrations:diff again

The migration generated by 3. will have a statement to change the dummy field, even though it wasn't changed:

ALTER TABLE dummy CHANGE dummy dummy INT DEFAULT 0 NOT NULL"

getCurrentVersion() throws SQL error when there is not yet migrated versions

Fails when there is not yet migrated versions: "IN ()" throws mysql error

public function getCurrentVersion()
{
...
/* BEFORE
$sql = "SELECT version FROM " . $this->migrationsTableName . " WHERE version IN (" . implode(', ', $migratedVersions) . ") ORDER BY version DESC";
*/

    /* AFTER */
    if (count($migratedVersions) > 0 ) {           
        $sql = "SELECT version FROM " . $this->migrationsTableName . " WHERE version IN (" . implode(', ', $migratedVersions) . ") ORDER BY version DESC";
    } else {
        $sql = "SELECT version FROM " . $this->migrationsTableName . " ORDER BY version DESC";
    }

...

}

Migrations per Bundle

Currently it is only possible to have a single folder with the migrations in it, usually in app/DoctrineMigrations. I don't know complicated this may be, or which pitfalls can appear, but I think it would be interesting, if it is possible to have different migrations per bundle. I thougt of something similar to DoctrineFixturesBundle, but for migrations.

Keeps droping and recreating the same index

Hi,

I odn't know if the problem is in doctrine migration or the dbal but anytime I do a migration diff, the last 2 lines are to drop and recreate those foreign keys (in the up and down methods).

Any idea of the source of the problem ?

$this->addSql("ALTER TABLE ordersdomains DROP FOREIGN KEY FK_D4D861CF8D9F6D38");
$this->addSql("ALTER TABLE ordersdomains ADD CONSTRAINT FK_D4D861CF8D9F6D38 FOREIGN KEY (order_id) REFERENCES `order` (id) ON DELETE CASCADE");

Time for a stable release?

As Symfony 2.3 SE has minimum stability set to stable this package isn't working. Why not create a stable release?

http://symfony.com/blog/upgrading-your-symfony-projects-the-easy-way

Downloadable PHAR not up to date

http://github.com/doctrine/migrations/blob/master/phar-cli-stub.php#L23

The downloadable PHAR (http://github.com/doctrine/migrations/downloads) fails the ClassLoader require_once as it doesn't reference phar://.