Doctrine Migrations: altering a column to be nullable in production

Question

I'm fairly new to Doctrine Migrations so apologies if this is really obvious.

Updated to provide more information

I have a Symfony2 entity mapping as below:

/**
 * @ORM\Column(type="string")
 */
private $name;

This was added to a migration and deployed with everything working as it should. The column then needed to be updated to accept null values so it was changed to:

/**
 * @ORM\Column(type="string", nullable=true)
 */
private $name;

The problem is that this has no impact on the resulting migration file:

$ php app/console cache:clear
$ php app/console doctrine:migrations:diff
$ tail -50 app/DoctrineMigrations/Version20131028205742.php

<?php

namespace Application\Migrations;

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

/**
 * Auto-generated Migration: Please modify to your needs!
 */
class Version20131028205742 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql", "Migration can only be executed safely on 'mysql'.");

    }

    public function down(Schema $schema)
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql", "Migration can only be executed safely on 'mysql'.");

    }
}

No ALTER statements have been added to handle null values. I could drop and rebuild the database but as this specific migration has already been deployed this will result in problems in the production database. I can see this situation occurring again in the future so would like to understand it a bit more.

Is this a limitation of Doctrine and/or the Symfony2 Doctrine Migrations bundle? Is there a way to get around this without writing a custom migration?

Please note, all my other migrations are working fine, the only issue is adding nullable options to existing fields.

Answer 1

Doctrine's diff works in that way it compares your entities metadata with existing database schema. So if you run doctrine:schema:update after you've ran the migration - doctrine doesn't notice any change because db schema is already changed (and therefore fits to entites metadata). And basically after you run the migration you don't need to run update anymore.