[DMIG-31] $table->renameColumn() actually drops the column Created: 23/Dec/11  Updated: 19/Jun/12  Resolved: 04/Jun/12

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Nikola Petkanski Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None
Environment:

symfony 2.0.7



 Description   

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;
}
..


 Comments   
Comment by Tyler Sommer [ 06/Feb/12 ]

Doctrine\DBAL\Schema\Table is actually not a part of Doctrine Migrations, rather just the Database Abstraction Layer project. Recommend this gets sorted as such.

Comment by David Buchmann [ 04/Jun/12 ]

this is a duplicate of DMIG-22

any chances of getting the issue fixed?

Comment by Benjamin Eberlei [ 04/Jun/12 ]

From the internals this is really complicated. I will delete the method instead.

Comment by Gonzalo Sainz-Trapaga [ 19/Jun/12 ]

Does this mean Doctrine Migrations won't support renaming columns? I'm sorry but the alternative of not supporting it at all doesn't really work. It's a basic operation for DB schema changes, which are the whole point of migrations. What exactly is the proble? I have seen the algorithms for inferring that a column or table should be renamed and they are pretty simplistic. Maybe the solution is adding some sort of hinting to the renameX operations so that there is metadata inside the Table Schemas saying what the original columns or tables were. Thoughts?





[DMIG-25] migrating muliple databases Created: 28/Jul/11  Updated: 17/Mar/12  Resolved: 17/Mar/12

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ajinder Singh Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

symfony2



 Description   

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.



 Comments   
Comment by Benjamin Eberlei [ 17/Mar/12 ]

This is not supported, Migrations works for exactly one database, not more.





[DMIG-39] Issue when using serjal columns in PostgreSQL with Doctrine ORM Identity fields Created: 24/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: postgresql, schematool
Environment:

PostgreSQL and migrations



 Description   

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.



 Comments   
Comment by Marco Pivetta [ 24/Apr/13 ]

This is a DBAL problem.

Please verify this with the DBAL diff tools (latest master) only and eventually report a DBAL issue without involving migrations.





[DMIG-40] DBAL Enum fields migration issue / PostgreSQL Created: 24/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: postgresql, schematool
Environment:

PostgreSQL and migrations



 Description   

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.



 Comments   
Comment by Marco Pivetta [ 24/Apr/13 ]

This is a DBAL issue. Please verify the issue using the DBAL schema tools (latest master) only and eventually open a DBAL issue.





[DMIG-34] Column names not escaped with backticks Created: 15/Feb/12  Updated: 15/Feb/12  Resolved: 15/Feb/12

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Matthew Baggett Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

MySQL & Linux



 Description   

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.



 Comments   
Comment by Benjamin Eberlei [ 15/Feb/12 ]

This is not a bug, you have to explicitly force escpaing manually by giving @Column(name="``key`") in your mapping (or xml/yml equivalent).

Automatic escaping leads to problems, that is why w edont support it.





[DMIG-23] Doctrine migrations MySQL only? Created: 14/Jul/11  Updated: 17/Nov/11  Resolved: 17/Nov/11

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Yaroslav Zenin Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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?



 Comments   
Comment by Kim Hemsø [ 16/Nov/11 ]

Seem this is already been fixed:

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

You can skip my PR-52, if you want since. My plan was to fix it with the query builder

Comment by Benjamin Eberlei [ 17/Nov/11 ]

Was already fixed





[DMIG-22] $table->renameColumn doesn't work Created: 21/Jun/11  Updated: 30/Jun/12  Resolved: 30/Jun/12

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Stefan Klug Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

php 5.3, current git master



 Description   

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



 Comments   
Comment by Benjamin Eberlei [ 30/Jun/12 ]

We removed the function because of that, see reason here https://github.com/doctrine/dbal/commit/9b0bd8817cb74c4aefba043c7e59f94641cc5b15





[DMIG-20] migrations try to create an index with name "primary" for ManyToMany associations Created: 06/Mar/11  Updated: 26/Jun/11  Resolved: 26/Jun/11

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: arnaud-lb Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 1
Labels: None


 Description   

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).



 Comments   
Comment by Karsten Dambekalns [ 25/Jun/11 ]

Caused by / related to DBAL-126

Comment by arnaud-lb [ 26/Jun/11 ]

Fixed by http://www.doctrine-project.org/jira/browse/DBAL-126





[DMIG-15] Drop not null is not working in Postgres Created: 16/Nov/10  Updated: 16/Nov/10  Resolved: 16/Nov/10

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lea Haensenberger Assignee: Jonathan H. Wage
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

Postgresql 8.4, Symfony 1.4, Doctrine 1.2



 Description   

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.



 Comments   
Comment by Lea Haensenberger [ 16/Nov/10 ]

I recreated the bug report in the doctrine 1 project since it rather belongs there.





[DMIG-12] createIndexSql and dropIndexSql don't use the same logic to get the index name Created: 28/Oct/10  Updated: 16/Nov/10  Resolved: 16/Nov/10

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lea Haensenberger Assignee: Jonathan H. Wage
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

Postgres 8.4



 Description   

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.



 Comments   
Comment by Lea Haensenberger [ 16/Nov/10 ]

I recreated the bug report in the doctrine 1 project since it rather belongs there.





[DMIG-9] table "contact_attribute" already exists - with mappedSuperClass Created: 25/Oct/10  Updated: 26/Nov/10  Resolved: 26/Nov/10

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sebastian Hoitz Assignee: Jonathan H. Wage
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Sebastian Hoitz [ 26/Nov/10 ]

This bug does not seem to occur anymore.





[DMIG-10] Syntax error in migration script Created: 27/Oct/10  Updated: 08/Dec/10  Resolved: 08/Dec/10

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sebastian Hoitz Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

The migration script created a php line like this:

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

Which creates a syntax error in the php file.



 Comments   
Comment by Jonathan H. Wage [ 08/Dec/10 ]

This should take care of it
https://github.com/doctrine/migrations/commit/44941f083eea1d321b7d7991a030ee303e9f9037





[DMIG-7] migrations:diff could not be found Created: 18/Aug/10  Updated: 15/Feb/11  Resolved: 15/Feb/11

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ting Wang Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux, http://svn.github.com/doctrine/migrations.git, revision 40


Attachments: Text File configDiff.patch    

 Description   

./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".



 Comments   
Comment by Benjamin Eberlei [ 15/Feb/11 ]

Fixed already





[DMIG-5] migrations:generate incorrect version Created: 21/Jun/10  Updated: 15/Feb/11  Resolved: 15/Feb/11

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tom Van Looy Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Linux Ubuntu



 Description   

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

$version = date('YmdHms');

must be

$version = date('YmdHis');



 Comments   
Comment by Benjamin Eberlei [ 15/Feb/11 ]

Fixed already.





[DMIG-4] Case sensitive include Created: 18/Jun/10  Updated: 18/Jun/10  Resolved: 18/Jun/10

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tom Van Looy Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux Ubuntu



 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 18/Jun/10 ]

Fixed issue with case in use statement http://github.com/doctrine/migrations/commit/eda8b0b0ee9f9bddb7b73ee956d2106e26b80794





[DMIG-3] AbstractCommand depends on ORM Package Created: 16/Jun/10  Updated: 16/Jun/10  Resolved: 16/Jun/10

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.






[DMIG-2] Creating columns of typ SET fails to set default value Created: 08/Jun/10  Updated: 08/Jun/10  Resolved: 08/Jun/10

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Fredrik Assignee: Jonathan H. Wage
Resolution: Fixed Votes: 0
Labels: None
Environment:

Doctrine 1.2.2
MySQL 5.0.45
PHP 5.2.5



 Description   

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()

{ $options = array( 'type' => 'set', 'notnull' => 1, 'size' => 10, 'values' => array( 'value_a', 'value_b', 'value_c', ), 'default' => 'value_a ); $this->addColumn('my_table', 'new_field', 'set', Null, $options); }

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) . "'";
}



 Comments   
Comment by Fredrik [ 08/Jun/10 ]

I hope I put this into the right project, wasn't sure if this belonged in "Doctrine 1" but this project is called "Doctrine Migrations" so here it went.

Comment by Jonathan H. Wage [ 08/Jun/10 ]

This is actually for the Doctrine 2 Migrations project. The Doctrine 1 migrations were a part of the actual Doctrine 1 library. Everything was all coupled together in Doctrine 1. We only split things up for Doctrine 2.

Comment by Fredrik [ 08/Jun/10 ]

Oh, I'm sorry. Should I create a new issue under Doctrine 1 to have it fixed there?

Comment by Jonathan H. Wage [ 08/Jun/10 ]

No, I already fixed the issue. Just for future reference





[DMIG-16] incorrect class name Created: 15/Jan/11  Updated: 15/Feb/11  Resolved: 15/Feb/11

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Documentation Priority: Minor
Reporter: Stepan Tanasiychuk Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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()"



 Comments   
Comment by Benjamin Eberlei [ 15/Feb/11 ]

Fixed.





[DMIG-11] Comparer always detects changes when using columnDefinition in mapping definitions Created: 28/Oct/10  Updated: 15/Feb/11  Resolved: 15/Feb/11

Status: Resolved
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Sebastian Hoitz Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Benjamin Eberlei [ 15/Feb/11 ]

Its not possible to fix this issue, its actually a drawback of using "columnDefinition", i started documenting this in the ORM docs.





[DMIG-44] Migration fails when removing index and a column with that index Created: 24/Jul/13  Updated: 24/Jul/13

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ilya Biryukov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Postgres 8.4, Cent OS 5


Attachments: File Cell.php    

 Description   

Migration fails:
SQLSTATE[42704]: Undefined object: 7 ERROR: index "idx_dae7c08213b1f670" does not exist

under these conditions:
1. Remove the index definition (indexes={@index(columns=

{"col"}

)})
2. Remove the column definiton on '$col'

What happens under the hood:
1. Column 'col' is dropped and all associated indexes are dropped automatically by the database
2. Doctrine tries to drop the index on 'col' which was already dropped.
3. Things blow up.

Possible solutions:
1. Append 'IF Exists' clause to 'drop index' command.
2. Rework the sequence of schema diffs, so that indexes are dropped before the columns are dropped






[DMIG-46] Wrong quotes escaping in diff migrations with Postgresql database Created: 08/Apr/14  Updated: 08/Apr/14

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Yevgenii Kolakovskiy Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql
Environment:

symfony 2.4, database_driver: pdo_pgsql



 Description   

With Postgresql database diff command generate wrong quotes escaping system names:

$this->addSql("CREATE INDEX IDX_F52993989395C3F3 ON "order" (customer_id)");

Cause - DMIG-10






[DMIG-41] Diff generated even if nothing changed (with solution) Created: 23/May/13  Updated: 23/May/13

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: And Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

To change this behavior:



 Comments   
Comment by Marco Pivetta [ 23/May/13 ]

What are the commands you ran?

Comment by And [ 23/May/13 ]

migrations:diff

$this->buildCodeFromSql return '$this->abortIf($this->connection->getDatabasePlatform()>getName() != "mysql", "Migration can only be executed safely on 'mysql'.");' on empty $this>getMigrateToSql





[DMIG-37] PostgreSQL generated SQL statements in migrations that use doublequotes create syntax errors in PHP Created: 28/Mar/13  Updated: 28/Mar/13

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: PostgreSQL, schematool
Environment:

PostgreSQL backend, using migration versions with field or schemanames that use reserved names.



 Description   

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!






[DMIG-36] Iterating over versions is very slow Created: 05/Mar/13  Updated: 22/Dec/13

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eric Durand-Tremblay Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

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;
}


 Comments   
Comment by Jeroen Thora [ 14/Jul/13 ]

We are experiencing the same problem, especialy when running migrations (plain sql queries) against a remote server. We have currently 4 migrations scripts, the first and second script contains the creation of around 10 tables (incl indexes, fk's, pk's, etc) this goes relativly fast (goes bit slower than running on a local server but that would be an amount of latancy) but when executing the third script (which only include a drop and create of an index) takes more than 60 seconds to execute. All these migration scripts are auto-generated by the diff tool

After a bit of debugging it looks like the createSchema() function is called every migration but each migration script the database gets more tables and so it will take each migration more time to finish the createSchema() function

The function is called here: https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Version.php#L243

First of all why is the create schema function needed to be executed and why every migration, because if you use plain sql migrations (auto-generated from mapping/entities) the migrations should just be executed, they don't need to know anything about the current state of the database except of the current migration version. So wouldn't it be a solution to check if the script containts plain sql or the migrations function and if it's just sql execute the migrations without checking the database

Comment by Jeroen Thora [ 22/Dec/13 ]

Benjamin Eberlei & Marco Pivetta any idea's/update on this issue?





[DMIG-35] Ignoring unique key Created: 07/Sep/12  Updated: 07/Sep/12

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: venu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: migrations, unique
Environment:

PHP 5.4.6-2~lucid
5.1.63-0ubuntu0.10.04.1-log



 Description   

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






[DMIG-30] Make :migrations:diff smart and generate Schema object changes, not SQL directly Created: 16/Nov/11  Updated: 28/Jan/14

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None

Attachments: Text File DMIG-30.patch    

 Description   

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.



 Comments   
Comment by Tyler Sommer [ 03/Feb/12 ]

I think this would be something that would greatly increase the usefulness of migrations.

After looking things over, I think doing something like this could work:

  • Instantiate an instance of Doctrine\ORM\Tools\Comparator, and retrieve a Doctrine\DBAL\Schema\SchemaDiff using $comparator->compare($fromSchema, $toSchema);
  • Iterate over each of the SchemaDiff's properties to retrieve new tables, dropped tables, columns, indexes, etc to generate both up and down code

It seems fairly simple, but I get kind of lost thinking about how it can be tested.

Another option, which may in the end be easier but more dirty, is to create a 'PhpPlatform' that only actually implements the getCreateTableSQL, getDropTableSQL, etc methods of Doctrine\DBAL\Platforms\AbstractPlatform.

Comment by Tyler Sommer [ 17/Feb/12 ]

I've gone and followed what I outlined in my last comment, but there is a small snag.

Comparator and SchemaDiff check for schema changes that are not possible to make using public methods. An example is a dropped index. Both Comparator and SchemaDiff support dropping indexes, but there is no Table#dropIndex to actually make it happen.

However, if you use Reflection to modify the underlying Table#$_indexes array, then the proper SQL will be generated by SchemaDiff. Terrible and dirty, I know. We should do something about it Should I create a ticket?

Anyway, I've attached a patch (based on the current master, 9e81984) of what I've come up with. I think I've covered everything. This will even generate code to drop indexes and foreign keys (using Reflection). I've tried it on a schema of around 90 entities and it works beautifully. Of course, it's definitely not done or ready, but I wanted to see what was thought about what I've done.

Finally, what would be considered an acceptable test for this kind of thing? I suppose if I refactor all of the code generating bits into individual methods, I could pretty easily test for expected output. Am I on the right track?

edit: by the way, use migrations:diff --no-platform to generate the migration

Comment by David Simon [ 28/Jan/14 ]

Note that there's also a PR for this change at https://github.com/doctrine/migrations/pull/79.

I just tried it out myself, rebasing on latest master, and it works great. Please consider merging, developers, this feature is awesome!





[DMIG-26] Remove implicit schema diff to sql in Migration tasks for explicit solution Created: 16/Nov/11  Updated: 21/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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);
}


 Comments   
Comment by Beau Simensen [ 20/Nov/11 ]

So each call to syncSchema() would result in processing all changes on the schema instance (dropTable(), etc.) to actual SQL commands and placed on the "operations" stack? And at that point the schema instance should show no diffs so that any future calls to syncSchema() would only include schema changes since the previous call?

Comment by Benjamin Eberlei [ 20/Nov/11 ]

Yes exactly

Comment by Beau Simensen [ 21/Nov/11 ]

Alright, I'll see what I can do. I have a feeling I will get a pretty good idea how everything works if I start digging into this one.





[DMIG-27] Add stack for operations Created: 16/Nov/11  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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.






[DMIG-28] Interactive :migrate execution: Show all commands that would be executed when pressing [y] Created: 16/Nov/11  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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.






[DMIG-29] Add callback operation Created: 16/Nov/11  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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!)






[DMIG-24] False positives in Comparator on default values Created: 14/Jul/11  Updated: 23/May/13

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Yaroslav Zenin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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?



 Comments   
Comment by And [ 23/May/13 ]

private $isActive = 1?

Comment by Marco Pivetta [ 23/May/13 ]

What are the affected versions for this bug? I think it is a DBAL schema comparator issue.

Comment by And [ 23/May/13 ]

And yes - related issue: http://www.doctrine-project.org/jira/browse/DDC-2467





[DMIG-21] Call to undefined method Doctrine\DBAL\Migrations\Tools\Console\Command\StatusCommand::getApplication() Created: 29/Mar/11  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lee Feistel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Doctrine 2.0.3, PHP 5.3.5



 Description   

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')) {


 Comments   
Comment by Romain D. [ 30/Mar/11 ]

I have this issue too with the "packaged" Doctrine 2.0.3 availible at http://www.doctrine-project.org/downloads/DoctrineORM-2.0.3-full.tar.gz.

Weirdly enough, the method is availible in the latest master, cf. https://github.com/symfony/Console/blob/master/Command/Command.php#L88

Comment by Wil Moore III [ 04/Apr/11 ]

I also confirm this behavior. I've also verified that this issue can be resolved by grabbing the latest (HEAD) from the Symfony repo.





[DMIG-19] migrations diff with columnDefinition Created: 06/Mar/11  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: arnaud-lb Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: None


 Description   

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






[DMIG-18] diffing causes lots of false positives (on postgresql) Created: 18/Feb/11  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None
Environment:

PostgreSQL 9.0



 Description   

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



 Comments   
Comment by Ilan [ 14/May/11 ]

I have noticed the same problems when using @GeneratedValue(strategy="IDENTITY").
Postgres will create a sequence which doctrine does not manage. When running a schema validation doctrine fails because the diff tool
believes the sequences should not be in the database.
Same problem when trying to update the schema with --complete, doctrine will run queries to drop the sequences.

Regards,

Ilan

Comment by Lukas Kahwe [ 05/Jul/11 ]

likely solved with http://www.doctrine-project.org/jira/browse/DBAL-42

Comment by Finjon Kiang [ 10/Sep/11 ]

Currently, sequences won't be dropped when using diff tool (latest version from github downloaded today). But it still drops the default value like 'nextval('xxx_seq')'. As the database wasn't used by doctrine2 only, dropping default value like that caused some problems in my environment.

Comment by Finjon Kiang [ 10/Sep/11 ]

well... the diff is not reliable currently as all the indexes, constraints were affected and serial, bigserial fields would be replaced using int and bigint...





[DMIG-17] bug in reverting migrations Created: 15/Jan/11  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Stepan Tanasiychuk Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 4
Labels: None
Environment:

Linux stfalcon-laptop 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:45:36 UTC 2010 x86_64 GNU/Linux
Installed packages, channel pear.doctrine-project.org:
======================================================
Package Version State
DoctrineCommon 2.0.0 stable
DoctrineDBAL 2.0.0 stable
DoctrineORM 2.0.0 stable

DoctrineMigration from git://github.com/doctrine/migrations.git (2.0 alpha?)


Attachments: Zip Archive Entities.zip     File migrations.yml     File Version20110115224434.php    

 Description   

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)



 Comments   
Comment by Karsten Dambekalns [ 13/Jun/11 ]

The problem is the missing constraint name. I looked up the name the constraint had and added it to the statement and it worked.

Since the names are generated by MySQL automatically, looking them up when generating the migration will probably not work, because the generated name might differ on another setup. What would work is creating names for the constraints and use them in create and drop operations.





[DMIG-8] MySQL + Doctrine 2 + Column of type decimal with no precision or scale manually set results in infinite migration diffs generated Created: 07/Oct/10  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Daniel Cousineau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Debian 5.0, PHP 5.3.3, MySQL 5.1.50, Doctrine 2.0.0BETA4, Annotations



 Description   

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.






[DMIG-6] Put Migrations under own namespace to avoid problems with Autoloader Created: 30/Jun/10  Updated: 16/Nov/11

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Marcus Stöhr Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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();


 Comments   
Comment by Jonathan H. Wage [ 30/Jun/10 ]

I am not sure we should do this. The migrations are an extension of the DBAL so it makes sense to be under that namespace. I thin it is normal to have to register the autoloaders in the right order, no?

Comment by Marcus Stöhr [ 01/Jul/10 ]

Yes, with the migrations being an extension of the DBAL I agree with you. As of today I wasn't aware of the fact that the autoloader using a stack (I should have checked that prior). However, it would be nice to have either some documentation about it or extend the ClassLoader to handle this implicit.

Comment by Jonathan H. Wage [ 01/Jul/10 ]

I will add some documentation about using multiple class loaders and order.





[DMIG-42] Invalid foreign key created for relationships using single table inheritance. Created: 03/Jun/13  Updated: 03/Jun/13

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Chris Collins Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL.



 Description   

This issue arises when associating an object that uses SINGLE_TABLE inheritance with another object. When the schema is updated, or migrations are created (I'm doing this via Symfony 2's doctrine:schema:update and doctrine:migrations:diff commands), a foreign key is added to the table that is valid for only one of the child classes.

A quick example: The aim here is to have a "user" type that can be associated to many "books" and "videos" (and other types not shown here) via a single table named "user_content" that contains a discriminator column and the ID of a video/book/other item of content.

/**
 * @ORM\Table(name="user_content")
 * @ORM\Entity
 * @ORM\InheritanceType("SINGLE_TABLE")
 * @ORM\DiscriminatorColumn("content_item_type", type="string")
 * @ORM\DiscriminatorMap({
 *     "Video" = "Video",
 *     "Book" = "Book"
 * })
 */
abstract class UserContent
{
}

/**
 * @ORM\Entity
 */
class UserVideo extends UserContent
{
    /**
     * @var Video 
     *
     * @ORM\ManyToOne(
     *     targetEntity="Video",
     *     inversedBy="userVideos"
     * )
     * @ORM\JoinColumn(name="content_item_id", referencedColumnName="id")
     */
    protected $contentItem;
}

/**
 * @ORM\Entity
 */
class UserBook extends UserContent
{
    /**
     * @var Book 
     *
     * @ORM\ManyToOne(
     *     targetEntity="Book",
     *     inversedBy="userBooks"
     * )
     * @ORM\JoinColumn(name="content_item_id", referencedColumnName="id")
     */
    protected $contentItem;
}

/**
 * @ORM\Entity
 * @ORM\Table(name="video")
 */
class Video
{
    /**
     * @var ArrayCollection
     *
     * @ORM\OneToMany(
     *     targetEntity="UserVideo",
     *     mappedBy="contentItem",
     *     cascade={"persist"}
     * )
     */
    protected $userVideos;
}

/**
 * @ORM\Entity
 * @ORM\Table(name="video")
 */
class Book
{
    /**
     * @var ArrayCollection
     *
     * @ORM\OneToMany(
     *     targetEntity="UserBook",
     *     mappedBy="contentItem",
     *     cascade={"persist"}
     * )
     */
    protected $userBooks;
}

/**
 * @ORM\Entity
 * @ORM\Table(name="user")
 */
class User 
{
    /**
     * @var ArrayCollection 
     *
     * @ORM\OneToMany(
     *     targetEntity="UserVideo",
     *     mappedBy="user",
     *     cascade={"persist"}
     * )
     */
    protected $userVideos;

    /**
     * @var ArrayCollection 
     *
     * @ORM\OneToMany(
     *     targetEntity="UserBooks",
     *     mappedBy="user",
     *     cascade={"persist"}
     * )
     */
    protected $userBooks;
}

When migrating/updating schema for this, you should see something like the following:

$this->addSql("CREATE TABLE user_content (id INT AUTO_INCREMENT NOT NULL, user_id INT DEFAULT NULL, content_item_id INT DEFAULT NULL, date_created DATETIME NOT NULL, content_item_type VARCHAR(255) NOT NULL, INDEX IDX_241429ABA76ED395 (user_id), INDEX IDX_241429ABCD678BED (content_item_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB");
$this->addSql("ALTER TABLE user_content ADD CONSTRAINT FK_241429ABA76ED395 FOREIGN KEY (user_id) REFERENCES user (id)");
$this->addSql("ALTER TABLE user_content ADD CONSTRAINT FK_241429ABCD678BED FOREIGN KEY (content_item_id) REFERENCES video(id)");

The first constraint is fine as "user_id" should always point at a row in the "user" table, but the second constraint is invalid: "content_item_id" will not always refer to an entry in the "video" table, it will sometimes refer to an entry in the "book" table, potentially throwing errors on inserts etc.

If I've done something incorrectly, misunderstood how this this type of inheritance should work or if you need further details, please let me know.






[DMIG-32] add annotation tag like author which defaults to current system username Created: 06/Feb/12  Updated: 06/Feb/12

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Justinas Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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.






[DMIG-47] Trailing whitespaces in diff Created: 20/Oct/14  Updated: 20/Oct/14

Status: Open
Project: Doctrine Migrations
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Attila Bukor Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The migrations tool puts trailing whitespaces to the empty lines between the abortIf and addSql calls when running a diff which is results in a smelly code.






Generated at Sat Nov 29 09:55:51 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.