When using Custom Doctrine DBAL Enums the migration created using diff

works fine the first time.

However the next time it generates a SQL statement trying to change to field type to INT from integer; (Redundant)
and a truncated statement:

"ALTER schemaname.fieldname SET" .. And that's it.

When using Doctrine ORM mapping fields like this:

    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @ORM\SequenceGenerator(sequenceName="schemaname.tablename_id_seq", allocationSize=1, initialValue=1)
     */
    private $id;

It first creates the migration perfectly as a serial column with the correct schema.

However when making a new migration diff it generates DROP statements for every sequence for these id, so we have to remove them manually every time.

When using some reserved field names in PostgreSQL DBAL, the generated SQL statements will quote those field names. (Make a table with fieldname "left" for example)

When the migrationversion is generated, the doublequote is not escaped:

addSQL("ALTER table x add column "left" integer");

This does not compile of course, should be

addSQL("ALTER table x add column \"left\" integer");

Regards!

When iterating migration versions, a call to SchemaManager::createSchema() is done for every versions. Four our schema, this call take about 1 second to execute. With already 30 migrations, this begin to be a problem.

$versions = $configuration->registerMigrationsFromDirectory($this->_migration_folder);
foreach($versions as $version){
    if(!$version->isMigrated()){
        $version->markMigrated();
    }

}

The problem is in Migrations\Configuration\Configuration::createMigrationTable() which does not set the migrationTableCreated flag when the table already exists.

public function createMigrationTable()
{
        $this->validate();

        if ($this->migrationTableCreated) {
            return false;
        }

        $schema = $this->connection->getSchemaManager()->createSchema();
        if ( ! $schema->hasTable($this->migrationsTableName)) {
            $columns = array(
                'version' => new Column('version', Type::getType('string'), array('length' => 14)),
            );
            $table = new Table($this->migrationsTableName, $columns);
            $table->setPrimaryKey(array('version'));
            $this->connection->getSchemaManager()->createTable($table);

            $this->migrationTableCreated = true;

            return true;
        }
        return false;
}

I have a table design style, which has api_id field with unique key
CREATE TABLE `design_style` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`api_id` varchar(5) COLLATE utf8_unicode_ci NOT NULL,
.....
PRIMARY KEY (`id`),
UNIQUE KEY `api_id` (`api_id`),
UNIQUE KEY `name` (`name`),
KEY `category_id_idx` (`category_id`),
CONSTRAINT `design_style_category_id_design_style_category_id` FOREIGN KEY (`category_id`) REFERENCES `design_style_category` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

I reverse engineered the database tables and created entities. I am using it in symfony2 app.

Then I executed
php app/console doctrine:schema:update --dump-sql
and also checked with migrations diff
php app/console doctrine:migrations:diff

but has given me
DROP INDEX api_id ON design_page

In my case $table->renameColumn('old', 'new') resulted only in a "drop column 'old'".

Tried to use renameColumn() into one of my migration scripts and it dropped the table.

The code does not seem okay as well:

namespace Doctrine\DBAL\Schema;
..
class Table extends AbstractAsset
{
..
  /**
    * 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;
}
..

I have 2 databases db1 and db2 in symfony2 + doctrine2 and both databases are different from each other in terms of tables and their fields.
I need to work on migration. Things work fine as long as there is one database.
But it does not works when there are more than one databases as it tries to migrate from all files [some of which are for db1, and some of them are for db2]
Also, is there any way where I can provide entity manager specific migration settings. Or is there any way through which I can provide connection or entity manager in the migration class.

Currently when using :migrations:diff the generated output will use addSql() exclusively. However there has to be a way to generate changes on the schema objects themselves by using the SchemaDiff objects and generating code from them.

Generated from an Entity with a variable named access_key, with a column name of "key".

Generated MySQL table constructor fails, name is not escaped with backticks.

would be nice if generated migrations could include @author tag with systems username
it would help when migrations are created by several users to find which migration belongs to who.

Currently the following leads to an implicit drop table statement:

public function up(Schema $schema)
 {
    $schema->dropTable("foo");
}

However this should be an explicit operation that internally puts everything onto the "addSQL" stack, then resets the schema diffs to zero by cloning the current schema into the "diff schema" again.

public function up(Schema $schema)
 {
    $schema->dropTable("foo");
    $this->syncSchema($schema);
    $schema->dropTable("bar");
    $this->syncSchema($schema);
}

Today I have started with implemention migrations in my project.
But I found that only MySQL supported.

/**
 * Returns the current migrated version from the versions table.
 *
 * @return bool $currentVersion
 */
  public function getCurrentVersion()
  {
      $this->createMigrationTable();

      $result = $this->connection->fetchColumn("SELECT version FROM " . $this->migrationsTableName . " ORDER BY version DESC LIMIT 1");
      return $result !== false ? (string) $result : '0';
  }

In my project I use MSSQL db.
Do you plan to use platform independent solution?

When DMIG-27 is implemented, add a new operation "callback" that is executed at the position in the stack and can do arbitrary things (for example use the EntityManager to migrate data!)

Up and down operations should only put commands on a stack that is then executed after up() or down() have been processed.

Currently there are two implicit stacks:

1. addSql()
2. The changes done to the $schema instance.

With DMIG-26 $schema is an explicit change that adds to a stack.

This should be unified to be one single stack called "operations" and they should be linearly processed.

Currently schema console only asks if you really want to do the migration, however you dont know what will actually happen.

all the operations should be posted before asking the question to do the migration.

I think it would be a good idea to put the Migrations classes under their own namespace. If you use \Doctrine\Common\ClassLoader for loading both, DBAL and Migrations, you need to load Migrations before DBAL to avoid raising an exception.

Throws exception:

$classLoader = new \Doctrine\Common\ClassLoader('Doctrine\DBAL', realpath(APPLICATION_PATH . '/../library/Doctrine/DBAL/lib'));
$classLoader->register();
$classLoader = new \Doctrine\Common\ClassLoader('Doctrine\DBAL\Migrations', realpath(APPLICATION_PATH . '/../library/Doctrine/Migrations/lib'));
$classLoader->register();

Works:

$classLoader = new \Doctrine\Common\ClassLoader('Doctrine\DBAL\Migrations', realpath(APPLICATION_PATH . '/../library/Doctrine/Migrations/lib'));
$classLoader->register();
$classLoader = new \Doctrine\Common\ClassLoader('Doctrine\DBAL', realpath(APPLICATION_PATH . '/../library/Doctrine/DBAL/lib'));
$classLoader->register();

I create entities from doctrine getting started tutorial http://www.doctrine-project.org/docs/orm/2.0/en/tutorials/getting-started-xml-edition.html
It's Bug, User, Project (in attach)
and create config migrations.yml (in attach)

after that i run command "./doctrine migrations:diff" which generated migration file Version20110115224434.php (in attach)
"./doctrine migrations:migrate" work normal
but "./doctrine migrations:migrate 0" dosn't work:

Migrating down to 0 from 20110115224434

– reverting 20110115224434

-> ALTER TABLE bug_product DROP FOREIGN KEY
Migration 20110115224434 failed during Execution. Error SQLSTATE[HY000]: General error: 1005 Can't create table 'doctrine2.#sql-531_108' (errno: 150)

[PDOException]
SQLSTATE[HY000]: General error: 1005 Can't create table 'doctrine2.#sql-531_108' (errno: 150)

I am playing around with the diff tool and noticing that a lot of false positives are generated, like using SERIAL creates Sequences that are not explicitly listed, causing the diff tool to believe that they should be dropped. Or using "array" as a datatype makes the diff tool believe that there was a type change since they are setup as TEXT. now the alter statement then actually specifies to alter it form TEXT to TEXT again.

I guess the fact is that just more work needs to be put in here and I guess if I want things to improve I should step up, especially if I care about such an "obsure" database as Postresql

At the moment I found only one way how to work with default values

/**
 * @var string $isActive
 *
 * @Column(name="isActive", type="boolean", nullable=false)
 */
private $isActive;

and then in the construct I use something like $this->setIsActive(true);
on db level it looks like "isActive BIT default 1"
But the problem happened when I try to compare schemas for migrations. It always false positives on defaults.

How to set defaults for prevent false positives in Comparator?

To reproduce:

Create a new entity with a column type decimal @Column(type="decimal")

Run the CLI tool "migrations:diff"

Run the CLI tool "migrations:migrate"

If you run "migrations:diff" again a new migration will be created with an ALTER TABLE that only affects the columns of type Decimal. You can apply these new migrations and generate more using Diff ad nauseum.

My assumption is there is a mismatch between the Migrations Diff and annotation's defaults, causing it to continually identify decimal columns as requiring a migration.

To avoid this issue manually set a precision and scale, everything will then work as expected.

When an attribute has a @Column(columnDefinition=...) parameter, migrations:diff always causes false positives.

I get the following error when trying to run doctrine migrations:status in a newly configured setup:

PHP Fatal error:  Call to undefined method Doctrine\DBAL\Migrations\Tools\Console\Command\StatusCommand::getApplication() in /library/vendor/migrations/lib/Doctrine/DBAL/Migrations/Tools/Console/Command/AbstractCommand.php on line 82

Changing line 82 of AbstractCommand.php to the following gets it working, but I am unsure of the implications:

if ($this->getHelper('db')) {

For ManyToMany associations, migrations try to create a unique index on (joinColumn, inverseJoinColumn) having name "primary":

CREATE UNIQUE INDEX primary ON join_table (joinColumn, inverseJoinColumn);

Which results in a syntax error on MySQL (primary is also an invalid key name).

http://www.doctrine-project.org/projects/migrations/2.0/docs/reference/introduction/en#introduction

$helperSet = new \Symfony\Components\Console\Helper\HelperSet(array(
'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($db),
'dialog' => new \Symfony\Components\Console\Helper\DialogHelper(),
));

bug in "\Symfony\Component_s_\Console\Helper\DialogHelper" => "\Symfony\Component\Console\Helper\DialogHelper()"

./doctrine list migrations didn't list diff although the diff command is added in doctrine.php.

This could be the problem of configure() in DiffCommand.php. The parent::configure() is called after the the configuration of diff command. So the name etc of the diff command is overwritten by the father class, namely "generate".

in Doctrine/DBAL/Migrations/Tools/Console/Command/GenerateCommand.php

$version = date('YmdHms');

must be

$version = date('YmdHis');

The migration diff command always thinks that my model definitions have changed, when I use the manual columnDefinition on a timestamp column:

    dateUpdated:
      type: datetime
      columnDefinition: TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL

This always results in a migration script like this:

<?php

namespace SuplifyApiMigrations;

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

class Version20101028121948 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        $this->_addSql('ALTER TABLE ticket CHANGE dateUpdated dateUpdated TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL');
    }

    public function down(Schema $schema)
    {
        $this->_addSql('ALTER TABLE ticket CHANGE dateUpdated dateUpdated DATETIME DEFAULT CURRENT_TIMESTAMP NOT NULL');
    }
}

As you can see, the columns look exactly the same. Doctrine just does not seem to parse the manual columnDefinition and compare its result.

The migration script created a php line like this:

$this->_addSql('ALTER TABLE ... DEFAULT '0'');

Which creates a syntax error in the php file.

I have a class App_Model_Contact_Attribute:

App_Model_Contact_Attribute:
  type: mappedSuperclass
  inheritanceType: SINGLE_TABLE
  table: contact_attribute
  discriminatorColumn:
    name: type
    type: string
    length: 20
    columnDefinition: "varchar(20) not null"
  discriminatorMap:
      emailAddress: App_Model_Contact_EmailAddress
      twitterAccount: App_Model_Contact_TwitterAccount
  id:
    id:
      type: integer
      columnDefinition: "int unsigned not null auto_increment"
      generator:
        strategy: AUTO
  fields:
    value:
      type: string
      notnull: true
      columnDefinition: "varchar(45)"
  manyToOne:
    contact:
      joinColumn:
        name: contactID
        referencedColumnName: id
        columnDefinition: "int not null unsigned"
      targetEntity: App_Model_Contact
      fetch: EAGER
      cascade: [persist]

and a class App_Model_Contact_EmailAddress and App_Model_Contact_TwitterAccount. Both yml files look similar to this:

App_Model_Contact_TwitterAccount:
  type: entity

Now, when I want to execute migrations:diff it always fails giving me the message: "Table contact_attribute already exists".

This probably has to do with the mappedSuperClass declaration in my models.

When removing the not null from a column the migration does not change anything in the database. This is due to the following check on line 162 of lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Export/Pgsql.php

if ( ! empty($field['definition']['notnull']))

So if notnull is not there or set to false or '0' or 0 the code does not enter into that if statement and therefore no changes are done to the not null value of the column.

In the class Doctrine_Export the functions for creating and dropping indexes do not use the same logic to get the name of the index to be created or dropped.

When creating an index $this->conn->quoteIdentifier() is called on the index name.
When dropping an index $this->conn->quoteIdentifier($this->conn->formatter->getIndexName()) is called on the name, which by default adds '_idx' to the index name. Hence, when an index should be dropped in a migration an index with that name is not found because it was created without the '_idx'.

We use the migrations with a Postgres 8.4 database.

in:
http://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Configuration/Configuration.php

use Doctrine\Dbal\Connection,
Doctrine\DBAL\Migrations\MigrationException,
Doctrine\DBAL\Migrations\Version,
Doctrine\DBAL\Migrations\OutputWriter,
Doctrine\Dbal\Schema\Table,
Doctrine\Dbal\Schema\Column,
Doctrine\DBAL\Types\Type;

This can't be upper/lowercase. DBAL must be in uppercase every time.

The Abstractcommand uses the Entity Manager instead of accessing the DBAL Connection directly through the helperset. This makes it impossible to use migrations without the ORM.

The ORM however is only of any interest in the DiffCommand, the other commands don't need access to any EM related functionality.

When writing a migration class for a table I wanted to add a new column of the SET type. I've set the notnull option and a default value, but Doctrine fails to generate the correct SQL.

Migration function:
public function up()

MySQL error (contains the generated SQL):
Error #1 - SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NOT NULL' at line 1. Failing Query: "ALTER TABLE my_table ADD new_field SET('value_a', 'value_b', 'value_c') DEFAULT NOT NULL"

After a bit of debugging I've found the problem, Doctrine_Formatter::quote() doesn't know how to handle set. Simply adding 'set' to the switch right below 'enum' will make it work as it should.

— lib/Doctrine/Formatter.php
+++ lib/Doctrine/Formatter.php
@@ -186,6 +186,7 @@ class Doctrine_Formatter extends Doctrine_Connection_Module
case 'blob':
case 'clob':
case 'enum':
+ case 'set':
case 'boolean':
return "'" . str_replace("'","''",$input) . "'";
}