Doctrine Project

[DC-1053] Renaming a doctrine 'string' field may result in loss of data as the field's type changes. (MySQL)

Mon, 26 Mar 2012 20:52:02 +0000

Consider the following schema:

schema.yml

MyTable:
  columns:
    some_text:        string

Doctrine creates the table with:

CREATE TABLE `my_table` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `some_text` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Now, the following migration should rename the field from some_text to just_text:

<?php
class Version1 extends Doctrine_Migration_Base
{
    public function up()
    {
        $this->renameColumn('my_table', 'some_text', 'just_text');
    }

    public function down()
    {
      $this->renameColumn('my_table', 'just_text', 'some_text');
    }
}

...however the field gets renamed and the type becomes VARCHAR(255), as the resulting SHOW CREATE TABLE my_table shows:

CREATE TABLE `my_table` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `a_varchar` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Causes data in the column greater than 255 bytes to get truncated

[DC-755] CLONE [DC-558] incorrect handling of MODEL_CLASS_PREFIX causes Doctrine_Migration_Diff to drop the whole database when working from YAML (Regression)

Sun, 10 Oct 2010 18:51:58 +0000

Replicating the bug:
1. Set ATTR_MODEL_CLASS_PREFIX non-null
2. create schema file with entity
3. run doctrine build-all
4. copy schema file
5. edit schema file to add column to entity
6. run generate-migrations-diff from copy of schema file to edited schema file

Expected (previous) behaviour:
Migration is generated to add the new column to entity

Real behaviour:
Drops entity from database and creates new

[DC-931] Newly generated Migration Classes failing to load due to method used to determine class name

Fri, 19 Nov 2010 02:04:00 +0000

The loadMigrationClassesFromDirectory() method in Doctrine_Migration uses array_diff on get_declared_classes() between including each classes script.

When a new migration class is generated by Doctrine_Core::generateMigrationsFromDiff it's class is loaded, which means loadMigrationClassesFromDirectory silently fails to load the newly generated migration on the same request. This means that scripts that first generate migrations and then apply them must be executed twice - first to generate then to apply.

The following example code is used to check if the database has been modifed, generate migrations between the base version and the latest models, and then migrate the database if needed:

automigrate.php

Doctrine_Core::generateYamlFromModels(ROOT_PATH.'tmp/yaml/', ROOT_PATH.'models/');
$result = Doctrine_Core::generateMigrationsFromDiff(ROOT_PATH.'tmp/migrations/', ROOT_PATH.'data/yaml/', ROOT_PATH.'tmp/yaml/');

unlink(ROOT_PATH.'data/yaml/schema.yml');
rename(ROOT_PATH.'tmp/yaml/schema.yml', ROOT_PATH.'data/yaml/schema.yml');

$migration = new Doctrine_Migration(ROOT_PATH.'tmp/migrations');

$currentVersion = $migration->getCurrentVersion();
$latestVersion = $migration->getLatestVersion();
if ($currentVersion < $latestVersion) {
	$migration->migrate();
	$this->app->addMessage("Database migration completed (from version $currentVersion to version $latestVersion)","success");
} else {
	$this->app->addMessage("Database is up to date and doesn't require migration (at version $currentVersion)","success");
}

[DC-929] createIndexSql and dropIndexSql don't use the same logic to get the index name

Wed, 7 Sep 2011 19:04:23 +0000

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

[DC-928] [Migrations] Drop not null is not working in Postgres

Tue, 16 Nov 2010 11:44:46 +0000

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.

[DC-888] Foreign key id columns do not respect ATTR_DEFAULT_IDENTIFIER_OPTIONS

Wed, 13 Oct 2010 13:03:15 +0000

Some time ago Jon Wage suggested that one can override the 8-byte default integer type for IDs by setting Doctrine_Core::ATTR_DEFAULT_IDENTIFIER_OPTIONS in configureDoctrine (in a Symfony project), like this:

public function configureDoctrine(Doctrine_Manager $manager)

{ // Use 4-byte IDs for backwards compatibility with databases built on // Apostrophe 1.4, sfDoctrineGuard pre-5.0, etc. You don't need this for // a brand new site $options = $manager->getAttribute(Doctrine_Core::ATTR_DEFAULT_IDENTIFIER_OPTIONS); $options['length'] = 4; $manager->setAttribute(Doctrine_Core::ATTR_DEFAULT_IDENTIFIER_OPTIONS, $options); }

This works for primary key id columns. However it is not respected by foreign key id columns, which do not consult ATTR_DEFAULT_IDENTIFIER_OPTIONS.

I looked at working around this using ATTR_DEFAULT_COLUMN_OPTIONS, however it is not type-specific. So if you set a length of 4 with that option, it applies not just to all integers but also to dates, datetimes, booleans and many other things that definitely should not be 4 bytes.

The correct fix seems to be for foreign key id columns to respect ATTR_DEFAULT_IDENTIFIER_OPTIONS.

Also, ATTR_DEFAULT_COLUMN_OPTIONS should probably let you specify different defaults for each column type as the length option is basically not usable in its current form. But that would not be a particularly clean solution to the foreign key id problem since limiting non-ID integers to 4 bytes should not be necessary.

The motivation for this bug report:

The new stable release of sfDoctrineGuardPlugin (for Symfony) does not specify an integer size as it formerly did, so the size of integers now defaults to 8 bytes. This breaks backwards compatibility with existing code that adds foreign key relationships to sfGuard objects like sfGuardUser, etc. Creating migrations to deal with changing this across all tables involved is quite difficult (all foreign key indexes must be dropped and recreated - doctrine:migrations-diff is unable to figure it out, understandably).

[DC-880] Versionable + I18n creates additional migration with irrelevant data

Mon, 19 Sep 2011 08:20:21 +0000

First run of generate-migrations-diff and migrate creates 2 migration diff files. First one for new tables, second one for new indexes and foreign keys. Than if I run generate-migrations-diff again another version is created although nothing was changed and following is inside:

1st entry tries to drop a foreign key never been created and not existing in file
next entry tries to create a foreign key already existing
3rd entry tries to create an existing index

After a long try and errorI found out that it's only happening with I18n plus Versionable behavior.

As I already have spent much time for a report please have also a look at: http://forum.diem-project.org/viewtopic.php?f=2&t=173&sid=5e0e3349c0e15a169bc9990a3104b3f6#p465

As I'm quite new to Doctrine and Symfony systems I cannot get further, but willing for more investigation if just one could give me a hint where to start.

[DC-867] Doctrine::ATTR_IDXNAME_FORMAT and Doctrine::ATTR_FKNAME_FORMAT are inconsistently applied during migrations

Wed, 7 Sep 2011 18:52:04 +0000

Given the following code:

    public function up()
    {
        $idx = array(
            'fields' => array('profile_id')
        );

        $this->addIndex('schedules', 'ix_schedules_profile_id', $idx);
    }
    public function down()
    {
        $this->removeIndex('schedules', 'ix_schedules_profile_id');
    }

The "up" function will try to create "ix_schedules_profile_id", but the "down" function will try to remove "ix_schedules_profile_id_idx". The same problem exists with foreign keys. The add/remove functions should both use the formatter, or neither should.

[DC-859] Diff generator doesn't load models from specified paths

Wed, 8 Sep 2010 07:21:42 +0000

Adding simple testcase, I have two version of PHP model, they differ in primary key.
version 0 has: stateid = Integer (classic id number)
version 1 has: stateid = char(2) (fixed length)

After I run Doctrine_Core::generateMigrationsFromDiff, doctrine will load only the integer model and compare it, so no difference is detected and no migration script created.

I'm attaching simple project where it doesn't work (adjust please LIBS_DIR definition for your setup).

From current codepath I would say when YAML is used, the from/to classes get prefixes.
When php model directories are used, the classes don't have have prefixes and their names are identical.
I think this may be one part of problem.

~~Trying to generate YAML files instead from php models lead to migration script dropping all tables. (looks like it's already reported as DC-755)~~
I did call both yaml generation and diff tool in the same script, which doesn't work. When I generate schema in other script and call diff tool on schemas later, it works.

Please, I'm willing to work on fix, but give me some ideas what should I try. (I thought about adding prefixes into php model files after they are copied into temp directory (to simulate YAML behavior), or bend the loading of models later, but I'm not sure the rest of code would cope with such fix, or there's more to do.

[DC-1037] Migration does not quote identifiers when checking migration version

Wed, 7 Sep 2011 20:13:23 +0000

I happen to be using Symfony 1.4.14-DEV (r33007) and am trying to setup migrations with Oracle, which is using Doctrine_Core::ATTR_QUOTE_IDENTIFIER. This issue is in core Doctrine.

To reproduce:

1. Make a change to your schema.yml
2. Create the migrations diff by executing php symfony doctrine:generate-migrations-diff
3. New file have been created at ./lib/migration/doctrine/*_version1.php
4. Try to migrate using command php symfony doctrine:migrate
5. Results in error:

ORA-00942: table or view does not exist : SELECT version FROM migration_version. Failing Query: "SELECT version FROM migration_version"

Cause: The current connection is using quoted identifiers, so the query used to create the migration_version table when migrations are first instantiated was properly created as "migration_version" (notice quotes). But the raw SQL query used in Doctrine_Migration::getCurrentVersion() is not quoting the table or column identifiers, so Oracle can't find the table.

There are several places in Doctrine_Migration where the table and column identifiers are not quoted, thus breaking migrations when using a database with strict rules on the case of identifiers.

Even though I'm developing against Oracle, this also likely affects other drivers.

[DC-1030] [PATCH] doctrine 1.2.4 ADD/DROP CONSTRAINT UNIQUE

Fri, 19 Aug 2011 12:02:34 +0000

Hi,

Adding/dropping UNIQUE CONSTRAINT doesn't work on PostgreSQL.

I'm attaching patch for this problem.

Best regards,
Michal

[DC-1022] Doctrine migration does not set version when MySQL autocommit is false

Tue, 26 Jul 2011 01:41:01 +0000

With autocommit set to off in mysqld, Doctrine_Migration::setCurrentVersion() does not have any effect. This is because the method uses raw PDO calls, which are discarded without either autocommit or an explicit COMMIT;.

We patched Doctrine as in the attachment. It works for us, but may not be the best general solution.

The patch only fixes this one issue. There are likely many areas in Doctrine that rely upon autocommit behavior in MySQL. We will continue to look for them, and supply patches as we find them. However, as we are only concerned about MySQL, our solutions will probably not apply to other PDO drivers.

[DC-988] migrations should allow generation of SQL in place of DB manipulation

Mon, 21 Mar 2011 12:44:19 +0000

At present migrations only allow for direct manipulation of the underlying database. However, many enterprise release processes disallow automated manipulation of databases (especially Oracle) due to a number of reasons (eg placing different objects in different table spaces).

Because of this, it is preferable for developers to auto generate SQL and then hand over the specialist DBAs who may then filter/alter as needed on a per-environment basis.

this is currently very easy to achieve with initial database query generation, as outputting SQL is an option, but there is no such option for migration scripts. Therefore I would like to request this option to be added to the migration class.

[DC-986] createIndexSql and dropConstant do not correct set index name suffix

Wed, 23 Mar 2011 10:52:48 +0000

Current export methods are inconsitent with index/constraint name suffix (defautl %_idx). Both createConstraintSql() and dropIndex() methods correctly set the suffix, but dropConstraint() and createIndexSql() do not.

this causes associated down() methods to fail when reverting changes to indexes/constraints

Erros occur in : Export.php - lines 137 and 473

[DC-985] doctrine migration does not use tblname_format

Mon, 21 Mar 2011 12:13:28 +0000

Migration commands update the database without correcting the default tablename using pre-set tblename_format parameters in databases.yml.

There is a method for updating the tablename, but this appears to not be used by any script.

[DC-440] doctrine migration fails with taggable extension

Fri, 22 Jan 2010 11:18:02 +0000

When adding the Taggable behaviour to an entity, the doctrine migration fails (i'm using the symfony task) with the follwing error:

>> doctrine Migrating from version 0 to 1

The following errors occurred:

SQLSTATE[23000]: Integrity constraint violation: 1217 Cannot delete or update a parent row: a foreign key constraint fails. Failing Query: "DROP TABLE taggable_tag"

I have a single entity in my schema, with the Taggable behavior attached:

Article:
actAs:
Taggable: ~
columns:
title:

{ type: string(255), notnull: true }

body:

{ type: clob }

The Version1 class which was generate by the generate-migrations-diff task looks like this:

<?php
/**

This class has been auto-generated by the Doctrine ORM Framework
*/
class Version1 extends Doctrine_Migration_Base
{
public function up() { $this->dropTable('taggable_tag'); }

public function down()

{ $this->createTable('taggable_tag', array( 'id' => array( 'type' => 'integer', 'length' => '8', 'autoincrement' => '1', 'primary' => '1', ), 'name' => array( 'unique' => '1', 'type' => 'string', 'length' => '255', ), ), array( 'type' => '', 'indexes' => array( ), 'primary' => array( 0 => 'id', ), 'collate' => '', 'charset' => '', )); }

}

[DC-383] Migrations not respecting ATTR_TBLNAME_FORMAT

Fri, 28 May 2010 06:13:28 +0000

I am using Doctrine 1.2.1 and Migrations don't appear to respect Doctrine::ATTR_TBLNAME_FORMAT when creating or dropping tables. This means while models create/drop tables with prefixes migrations don't. Also the migration_version table is created without the prefix too even though it was apparently fixed in ~~DC-245~~.

I haven't tested but it also probably means other attributes like Doctrine::ATTR_IDXNAME_FORMAT and Doctrine::ATTR_SEQNAME_FORMAT are not obeyed either which makes things a little confusing knowing when to care for prefixes or not.

[DC-667] migration fails for long foreign key names

Thu, 6 May 2010 09:19:20 +0000

When having a model with short name and i18n field which is versioned, everthing is right. There are no problems when doing diff and migration again and again. Nothing will happen because nothing changed.
For example:
mytest:
actAs:
I18n:
fields: [ description_front ]
actAs:
Timestampable:
Versionable:
columns:
title:

{type: string(255)}

description_front:

{type: string(255)}

But when using a longer model name like 'mytestmytestmytest' then some strange errors occurred in my simple example. After creating the 'translation' and 'transalation_version' table in '1273139712_version2.php' and creating the foreign keys in '1273139713_version3.php' there shouldn'd be a '1273146011_version4.php' generated by doing a diff, because everthing was already done. And of course when doing a migration with this last version, you will get errors.

[DC-617] migration problem

Fri, 22 Jun 2012 14:01:48 +0000

I attached a testcase that reproduces all problem that I noticed (previously reported in "serious symfony doctrine:migrate issues - symfony 1.4" on symfony-dev)

There is a problem with an empty ON UPDATE when migrate to version 5

SQLSTATE[42601]: Syntax error: 7 BŁĄD: błąd składni w lub blisko "ON"
LINE 1: ... (object_c_id) REFERENCES object_c(id) ON UPDATE ON DELETE ...
^. Failing Query: "ALTER TABLE object_b ADD CONSTRAINT object_b_object_c_id_object_c_id FOREIGN KEY (object_c_id) REFERENCES object_c(id) ON UPDATE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE"

When migrateing from 5 to 3
Failing Query: "DROP INDEX object_b_object_c_id_idx" - this index doesn't exist - should be "object_b_object_c_id"

Also
$this->changeColumn('object_a', 'name', 'string', '2048', array(
));
$this->changeColumn('object_b', 'name', 'string', '2048', array(
));
doesn't work for me

[DC-834] When altering an existing column PGSQL can't convert to SERIAL for autoincrement

Wed, 18 Aug 2010 12:36:45 +0000

If you have an existing column Postgresql won't allow you to use the type SERIAL for altering the column.

First create a column cat_id on category of integer type. Then run the following migration:

migration.php

    public function up()
    {
        $this->changeColumn('category', 'cat_id', 'integer', '4', array(
             'unsigned' => '',
             'primary' => '1',
             'autoincrement' => '1',
             ));
    }

Instead of using type SERIAL doctrine would have to simply alter the column then add a sequence on it's own.

[DC-830] Migration for up() not adding suffix for index

Sat, 21 Aug 2010 07:06:10 +0000

I am still getting the same issue as previously closed a while ago on trac http://trac.doctrine-project.org/ticket/1964

migration.php

<?php
/**
 * This class has been auto-generated by the Doctrine ORM Framework
 */
class Add_Category_Slug_Index extends Doctrine_Migration_Base
{
    public function up()
    {
        $this->addIndex('category', 'category_sluggable', array(
             'fields' => 
             array(
              0 => 'slug',
             ),
             'type' => 'unique',
             ));
    }

    public function down()
    {
        $this->removeIndex('category', 'category_sluggable', array(
             'fields' => 
             array(
              0 => 'slug',
             ),
             'type' => 'unique',
             ));
    }
}

The above migration generates an index named category_sluggable instead of category_sluggable_idx

[DC-827] Custom Doctrine_Query UPDATE statement inside migration scope not working

Tue, 2 Nov 2010 06:28:34 +0000

I found strange problem in Doctrine migration. I tried to execute custom DQL in migration. Custom query with SELECT statement succeed, but UPDATE query not changed any data in DB and do not returned back any error message. After I tried execute same code in CLI task. Worked well and data in database was updated as I expected. So looks like Doctrine_Query do not works well inside migration scope with UPDATE statement.

... or maybe I do something wrong? If did something maybe you have to put in manual how to use custom DQL in migrations correctly. I hope migrations are not only to change structure of tables, but also can be used to change data structure too.

 
public function up() {

$conn = Doctrine_Manager::connection();  	  	
  	
$brands = Doctrine_Query::create ($conn)
  		->select('b.id, b.name')
  		->from('Brand b')
  		->fetchArray();  // this query worked for me well. I have data
  		 	  	  	 	  	
foreach ($brands as $brand) {
  Doctrine_Query::create ($conn)
   	->update('Brand')
  	->set('safe_name', '?', 'some_safe_name')
  	->where('id = ?', $brand['id'])
  	->execute(); // this query was executed but not had any effect on data in DB
 }
//........

[DC-768] Renaming a NOT NULL column without a default value fails in MySQL migrations

Fri, 28 Jan 2011 10:29:50 +0000

When trying to rename a column that is NOT NULL and has no default value, Doctrine generates this SQL:

ALTER TABLE `article` CHANGE `typeid` `listid` INT DEFAULT NULL NOT NULL

Which fails. It should be:

ALTER TABLE `article` CHANGE `typeid` `listid` INT NOT NULL

[DC-753] doctrine generate-migrations-diff throws "No php or yml files found at path"

Thu, 27 Jan 2011 13:07:37 +0000

I am trying to generate migrations from the CLI but I get the error mentioned in the title. I did some searching and this seems to have been a known problem and was fixed, however, I'm getting it and the path is correct, and there is even a schema.yml file I just generated, also through CLI.

Here is the error:

D:\wamp\www\project\src\administrator\components\com_project\doctrine>php doctrine generate-migrations-diff
No php or yml files found at path: "D:\wamp\www\project\src\administrator\components\com_project\doctrine\schema"

And here is what I have in my CLI file:

require_once('../../../../libraries/doctrine/lib/Doctrine.php');

spl_autoload_register(array('Doctrine','autoload'));

Doctrine_Manager::connection('mysql://root@localhost/project','default');

//Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_TBLNAME_FORMAT, 'jos_project_%s');
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_ALL);
Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_QUOTE_IDENTIFIER, true);
Doctrine::loadModels('models/generated');
Doctrine::loadModels('models');

$cli = new Doctrine_Cli(array(
'data_fixtures_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'fixtures',
'models_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'models',
'migrations_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'migrations',
'sql_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'sql',
'yaml_schema_path' => dirname(_FILE_).DIRECTORY_SEPARATOR.'schema'
));

$cli->run($_SERVER['argv']);

I find this very weird because earlier today I was able to make a migration the same way but with Symfony's CLI, however, that is another project.

Regards,

David

[DC-750] migration error when deleting 2 or more related classes

Thu, 1 Jul 2010 05:29:04 +0000

That's my relevant schema.yml before changes:

Customer:
columns:
[..]

CustomerPlace:
columns:
[..]
relations:
Customer:
local: customer_id
foreignAlias: Addresses
onDelete: CASCADE

CustomerPerson:
columns:
[..]
relations:
CustomerPlace:
local: place_id
foreignAlias: Contacts
onDelete: CASCADE

I deleted all of the 3 entities, I executed symfony doctrine:generate-migrations-diff, which created the migration file containing:

    
        $this->dropTable('customer');
        $this->dropTable('customer_person');
        $this->dropTable('customer_place');

Executing the migration, gave me error for constrain violation. To fix the error, I added:

        $this->dropForeignKey('customer_person', 'customer_person_place_id_customer_place_id');
        $this->dropForeignKey('customer_place', 'customer_place_customer_id_customer_id');

Thanks.

[DC-751] [PATCH] fix migration builder for remove index

Fri, 18 Jun 2010 03:44:21 +0000

remove the third argumnet it is not used/defined

[DC-1028] Doctrine Migrate functions for current version and for creating the migrations table

Tue, 16 Aug 2011 18:54:25 +0000

I always tend to find myself needing to implement migrations after the fact. It would be really nice to have a method of having doctrine creating the migration_version table as well as a method of setting that value and getting that value.

This would in-turn allow the implementation in a framework such as symfony to allow you insert the table after the fact, allow you to update the migration version without running the migration and to let you know what version you're currently on.

[DC-597] symfony doctrine:generate-migrations-diff task doesn't take attributes into account

Tue, 8 Jun 2010 16:17:57 +0000

I provided the following bug report on the symfony website and was redirected here. The response I received was:

Ticket #8438 (closed defect: invalid)
03/20/10 12:55:04 changed by Kris.Wallsmith

status changed from new to closed.
resolution set to invalid.

The symfony task is a wrapper for the Doctrine task. Please post issues to their Jira. http://www.doctrine-project.org/jira

------------------
Bug details:
------------------

When running doctrine:generate-migrations-diff, I am receiving foreign key files. However, my schema.yml is defined as such:

attributes:
export: tables
TableOne:
columns:
...
TableTwo:
columns:
...

It would appear that when running doctrine:build it properly ignores the foreign key generation, but that it does not when running doctrine:generate-migrations-diff. This task should be corrected to take this attribute into account. Keep in mind that this may be relevant to the other migration tasks, and they should be updated as well if this is a valid bug.

[DC-497] A new task to set migration to a certain version

Sat, 13 Feb 2010 01:55:11 +0000

It would be nice to have a task which you could tell to set to the proper version. If the migrations_version table did not exist yet, it would create the table and set the version.

Explanation:
Most times migrations come as an after thought after the code db is already pushed live. Therefore you have to manually create the migrations table and set it to a version just before the newest migration.

It might also be better to just update the migrate task to check if a migration_version table exists, if not to just run the single migration which is specified.

[DC-803] Syntax error in MySQL migration to drop constraint (patch supplied)

Thu, 29 Jul 2010 11:58:16 +0000

I have a migration that adds constraints correctly. When migrating down, however, I get a syntax error

ErrorMessage

  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 'CONSTRAINT unique_username_idx' at line 1. Failing Query: "ALTER TABLE conUser DROP CONSTRAINT unique_username_idx"

Here is the down migration:

DownMigration

    public function down() {
        $this->dropConstraint('conUser', 'unique_username_idx');
    }

The SQL generated is "ALTER TABLE conUser DROP CONSTRAINT unique_username_idx". This post (http://forums.mysql.com/read.php?98,70887,70974#msg-70974) suggests that in MySQL the syntax should be "ALTER TABLE conUser DROP INDEX unique_username_idx" as constraints are basically indexes in MySQL (unlike MSSQL and Oracle). Doctrine's lib/Doctrine/Export/MySql.php appears to have a syntax error in the dropConstraint method. I attach a patch for this, but the only change is replacing "$name = 'CONSTRAINT '" with "$name = 'INDEX '" in dropConstraint. The migration then runs as I would expect.

Sorry if this has been fixed elsewhere, I did a search but couldn't find a similar ticket.

[DC-767] Doctrine_Migration_Builder::generateMigrationClass() improperly loads migration class

Fri, 25 Jun 2010 11:03:13 +0000

in function: Doctrine_Migration_Builder::generateMigrationClass() the generated migration class is included (require_once) after creation. A loadMigrationClass call is made following [line 513] as:

$this->migration->loadMigrationClass($className);

I propose this should change to include the optional "$path" argument to Doctrine_Migration::loadMigrationClass() as:

$this->migration->loadMigrationClass($className, $path);

Since the $path variable is available for the loadMigrationClass it should be included. More importantly NOT including $path breaks the certains behaviors. This occurs as a side effect in symfony for instance when creating a new task that chains:

doctrine:generate-migrations-diff
doctrine:migrate

The reason for the problem is because the generate-migrations-diff properly creates the version class and file and then has a require_once that pulls the class into scope. doctrine:migrate then runs Doctrine_Migration::loadMigrationClassesFromDirectory() to find all the migration classes. The task does NOT see the newly created migration class because it is not associated with the directory dirname($path) pointed out above. The function thoroughly scans the migration class directory with require_once and array_diff's to find new classes. But the new migrations class is already within declaration scope so is missed. Thus the doctrine:migrate task always migrates to the version BEFORE the executed doctrine:generate-migration-diff.