[DC-1053] Renaming a doctrine 'string' field may result in loss of data as the field's type changes. (MySQL) Created: 26/Mar/12  Updated: 26/Mar/12

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

Type: Bug Priority: Critical
Reporter: Ben Lancaster Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.3.5-1ubuntu7.2ppa1~lucid with Suhosin-Patch (cli) (built: May 7 2011 03:12:27)
Zend Engine v2.3.0
Xdebug v2.0.5
Turnkey LAMP 10.04 LTS x86_64
Symfony 1.4.11
mysql Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (i486) using readline 6.1



 Description   

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) Created: 20/Jun/10  Updated: 10/Oct/10

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

Type: Bug Priority: Critical
Reporter: Andrew Coulton Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Current HEAD of Doctrine 1.2


Attachments: File dc755TestCase.diff     File fix755.diff    

 Description   

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



 Comments   
Comment by Andrew Coulton [ 20/Jun/10 ]

This seems to be a regression caused by the fix for DC-558 which added the MODEL_CLASS_PREFIX to the $_toPrefix in Doctrine_Migration_Diff::generateChanges.

While this fixed the issue when generating diff from models to YAML, it has now created the reverse issue for generating diffs from YAML to YAML - as the models generated for the "from" schema do not get MODEL_CLASS_PREFIX prepended and so now this command will drop all existing tables and recreate.

I believe the fix may be to amend as:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
        $from = $this->_generateModels(
            Doctrine_Manager::getInstance()->getAttribute(Doctrine_Core::ATTR_MODEL_CLASS_PREFIX) . self::$_fromPrefix,
            $this->_from);
        $to = $this->_generateModels(
            Doctrine_Manager::getInstance()->getAttribute(Doctrine_Core::ATTR_MODEL_CLASS_PREFIX) . self::$_toPrefix,
            $this->_to                
        );

Since it seems that when presented with a folder of models _generateModels ignores the prefix anyway. However, I'm not sure of other impacts possible as a result?

Comment by Andrew Coulton [ 29/Aug/10 ]

I've been using and testing the modified version above locally for some time and it seems to work as expected. Any chance of this making it into core? Otherwise, the migrations feature is completely unusable when working YAML-YAML and using model prefixes on the newly released 1.2.3

Comment by Jonathan H. Wage [ 29/Aug/10 ]

Has anyone been able to produce this in a test case?

Comment by Andrew Coulton [ 30/Aug/10 ]

I've attached a diff file with the DC755TestCase and the required from and to YAML schema files to reproduce this bug. I wasn't sure whether you prefer like this or as a git commit?

Comment by Andrew Coulton [ 30/Aug/10 ]

Also attached a diff file of my proposed change to Doctrine_Migration_Diff to resolve this, but as I say unsure if it has implications on other migration types.

Comment by Andrew Coulton [ 10/Oct/10 ]

Fixed by http://github.com/acoulton/doctrine1/tree/DC-755





[DC-1037] Migration does not quote identifiers when checking migration version Created: 07/Sep/11  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: John Kary Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux version 2.4.21-63.ELsmp (mockbuild@x86-005.build.bos.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-59)) #1 SMP Wed Oct 28 23:15:46 EDT 2009, Symfony 1.4.14-DEV, Oracle 11g



 Description   

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.



 Comments   
Comment by John Kary [ 07/Sep/11 ]

Pull request open which quotes all identifiers in Doctrine_Migration and fixes this issue:
https://github.com/doctrine/doctrine1/pull/41





[DC-1030] [PATCH] doctrine 1.2.4 ADD/DROP CONSTRAINT UNIQUE Created: 19/Aug/11  Updated: 19/Aug/11

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

Type: Bug Priority: Major
Reporter: MichalKJP Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File symfony_0010_doctrine_fix_unique_add_drop.patch    

 Description   

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 Created: 26/Jul/11  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Adam Fineman Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

RHEL 6.0, mysql 5.1.52


Attachments: Text File migration.patch    

 Description   

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-986] createIndexSql and dropConstant do not correct set index name suffix Created: 21/Mar/11  Updated: 23/Mar/11

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

Type: Bug Priority: Major
Reporter: David Dixon Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

linux, oracle



 Description   

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-988] migrations should allow generation of SQL in place of DB manipulation Created: 21/Mar/11  Updated: 21/Mar/11

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

Type: Improvement Priority: Major
Reporter: David Dixon Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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-985] doctrine migration does not use tblname_format Created: 21/Mar/11  Updated: 21/Mar/11

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

Type: Bug Priority: Major
Reporter: David Dixon Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

linux, oracle



 Description   

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-931] Newly generated Migration Classes failing to load due to method used to determine class name Created: 19/Nov/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.0-ALPHA1, 1.2.0-ALPHA2, 1.2.0-ALPHA3, 1.2.0-BETA1, 1.2.0-BETA2, 1.2.0-BETA3, 1.2.0-RC1, 1.2.0, 1.2.1, 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Adam Benson Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

LAMP



 Description   

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-928] [Migrations] Drop not null is not working in Postgres Created: 16/Nov/10  Updated: 16/Nov/10

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

Type: Bug Priority: Major
Reporter: Lea Haensenberger Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Postgresql 8.4, Symfony 1.4, Doctrine 1.2


Attachments: Text File dropNotNullPatch.patch    

 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 Lukas Kahwe [ 16/Nov/10 ]

@Lea: can you write up a patch for this? would also be nice if you could check if the same issue affects other drivers.

Comment by Lea Haensenberger [ 16/Nov/10 ]

Here is a patch (attachment). The generate-migrations-diff Task in Symfony sets 'notnull' to an empty string if it's false in the schema.yml, therefore the check for empty string.

I had a quick look at the classes for other DBs, but that seems to be a postgres only issue.





[DC-929] createIndexSql and dropIndexSql don't use the same logic to get the index name Created: 16/Nov/10  Updated: 07/Sep/11

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

Type: Bug Priority: Major
Reporter: Lea Haensenberger Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Postgresql 8.4, Symfony 1.4, Doctrine 1.2



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



 Comments   
Comment by Lukas Kahwe [ 16/Nov/10 ]

looks to me like this is a bug in index creation. then again fixing the bug will lead to potential BC issues. that being said, anyone affected could "simply" set the index format to empty. also "fixing" the names to the proper format does not require shuffeling around data. so imho the right fix would be to apply the drop naming logic in the create logic.

what surprises me is that the main reason for appending _idx by default was that many RDBMS will otherwise break because they do not separate identifiers between constraints and indexes etc and therefore people run into collisions without the postfix.

Comment by John Kary [ 07/Sep/11 ]

Related/Duplicate of DC-830 and DC-867.





[DC-888] Foreign key id columns do not respect ATTR_DEFAULT_IDENTIFIER_OPTIONS Created: 13/Oct/10  Updated: 13/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Migrations, Relations, Schema Files
Affects Version/s: 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tom Boutell Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Any



 Description   

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 Created: 06/Oct/10  Updated: 17/Apr/14

Status: Open
Project: Doctrine 1
Component/s: Behaviors, I18n, Migrations, Relations
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

PHP 5.2, Symfony 1.4, Diem 5.1, Doctrine 1.2.2



 Description   

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.



 Comments   
Comment by Andrew Coulton [ 10/Oct/10 ]

I think this is because the versionable behaviour doesn't define a table name in the Doctrine_Template_Versionable class. As a result, if using model prefixes, the prefixes are not discarded from the table names when the behaviour model classes are built. This means that the tables have different names to what is expected, so they have different index keys, so the indexes are dropped and recreated as part of the migration.

I have committed unit tests and patch for this issue (which applies to Searchable also) to http://github.com/acoulton/doctrine1/tree/DC-880

Comment by Daniele Dore [ 19/Sep/11 ]

I experienced the same problem in the latest version 1.2.4, and the patch proposed by Andrew Coulton solves the problem.
Why the fix is not included in official release?





[DC-867] Doctrine::ATTR_IDXNAME_FORMAT and Doctrine::ATTR_FKNAME_FORMAT are inconsistently applied during migrations Created: 15/Sep/10  Updated: 07/Sep/11

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

Type: Bug Priority: Major
Reporter: Ryan Lepidi Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

postgres 8.4



 Description   

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.



 Comments   
Comment by John Kary [ 07/Sep/11 ]

Appears to be duplicate of DC-830





[DC-859] Diff generator doesn't load models from specified paths Created: 06/Sep/10  Updated: 08/Sep/10

Status: Open
Project: Doctrine 1
Component/s: Migrations
Affects Version/s: 1.2.2, 1.2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Peter Helcmanovsky Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

WinXP, PHP 5.3.3


Attachments: Zip Archive Doc1_migration_model_loading_bug.zip    

 Description   

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.



 Comments   
Comment by Peter Helcmanovsky [ 06/Sep/10 ]

Another potentional fix is to not copy model files into temp dir, but generate YAML from them, and then generate prefixed models trough YAML code path.
Doesn't sound effective, but as long as YAML path will be fixed, it may work?

Comment by Peter Helcmanovsky [ 08/Sep/10 ]

One more idea for how it can be done ( ? ):
to create temporary php script in temp dir together with from model files, run it, let it generate $fromInfo data, serialize them on disk, do the same with to models and get another serialized data, then load those files into $fromInfo and $toInfo and do the actual diffing.

The point is that by running the small temporary script in new process it would be able to load model files from disk as classes without prefixing/changing them, create the $info data, and exit, so the newer classes with same name can be loaded again in the another new thread. The diff then has to live with serialized $info data only without loading model classes.





[DC-834] When altering an existing column PGSQL can't convert to SERIAL for autoincrement Created: 18/Aug/10  Updated: 18/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Attributes, Migrations
Affects Version/s: 1.2.2
Fix Version/s: None

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

PostgreSQL 8.4



 Description   

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 Created: 16/Aug/10  Updated: 21/Aug/10

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

Type: Bug Priority: Major
Reporter: webPragmatist Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Postgresql 8.4 / Symfony 1.4.6



 Description   

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



 Comments   
Comment by webPragmatist [ 16/Aug/10 ]

If I change the name in the up() to category_sluggable_idx both up and down work properly.

Comment by Jakub Argasiński [ 21/Aug/10 ]

Confirming. I had the same problem last week and as a workaround I had to change suffix from "%s_idx" to "%s". Even if the bug is not reproducible in a test case, it indeed happens in live environment on PostgreSQL (in my case, Symphony is not used).





[DC-827] Custom Doctrine_Query UPDATE statement inside migration scope not working Created: 14/Aug/10  Updated: 02/Nov/10

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

Type: Bug Priority: Major
Reporter: Arnoldas Lukasevicius Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony Framework 1.3
Zend Server CE 5.0.2 (PHP 5.3.2)
Apache 2.2
MySQL 5.1.47
Windows XP



 Description   

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 Created: 25/Jun/10  Updated: 28/Jan/11

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

Type: Bug Priority: Major
Reporter: Jack Sleight Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None

Attachments: Text File DC-768.patch    

 Description   

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


 Comments   
Comment by Matthew Hughes [ 11/Jan/11 ]

can confirm this behaviour on mysql w/ 1.2.4

Comment by Matthew Hughes [ 28/Jan/11 ]

Attached is a patch that solves the issue.
It's not the most elegan solution.
But works and all tests pass.





[DC-753] doctrine generate-migrations-diff throws "No php or yml files found at path" Created: 19/Jun/10  Updated: 27/Jan/11

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

Type: Bug Priority: Major
Reporter: David Vega Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

WIndows 7 x64, WAMP, PHP 5.2.11 & 5.3



 Description   

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



 Comments   
Comment by Marcelo Saldanha [ 27/Jan/11 ]

I have the same problem, using symfony 1.4 latest sources. After reading about 20 (long) pages about similar issues, I've come up with a solution.

The problem appears when the project still don't have any Models defined. Im my case, they were all new projects in the plugin activation stage. Curiously, the behaviour were random, as in some projects I could activate my Contacts plugin (the first), and in others I couldn't.

After much consideration, the problem was that the var $extension in /doctrine/Doctrine/Migration/Diff.php was empty, and that was because the algorithm only considered the first entry of the directory. If it was a file, its extension was used. If not, the algorithm descended until it found a file as the first entry. BUT it never considered second (and following) entries, so as my first entry was the 'base' directory, and it was empty, no extension was ever found. This probably will not happen if the project have some models defined.

And so, I came up with a solution. In doctrine/Doctrine/Migration/Diff.php, enclose this code in the _getItemExtension method (near line 350, in my copy) with a loop, such as:
$idx = 0;
while (strlen($extension) == 0) {
if (isset($files[$idx])) {
if (is_dir($files[$idx]))

{ $extension = $this->_getItemExtension($files[$idx]); }

else

{ $pathInfo = pathinfo($files[$idx]); $extension = $pathInfo['extension']; }

$idx++;
}
else break; // no more entries to seek
}

Now it keep looking in every folder until it finds a file WITH an extension, and stops when all the tree is searched.

Hope that helps someone.

best regards.





[DC-751] [PATCH] fix migration builder for remove index Created: 18/Jun/10  Updated: 18/Jun/10

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

Type: Bug Priority: Major
Reporter: Gordon Franke Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File remove_index.patch    

 Description   

remove the third argumnet it is not used/defined






[DC-750] migration error when deleting 2 or more related classes Created: 17/Jun/10  Updated: 01/Jul/10

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

Type: Bug Priority: Major
Reporter: Giovanni Toraldo Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Giovanni Toraldo [ 01/Jul/10 ]

Another way for fixing this issue, could be to generate a migration class for each of the related tables, so they are executed in different transaction, so integrity constrains aren't violated.





[DC-667] migration fails for long foreign key names Created: 06/May/10  Updated: 06/May/10

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

Type: Bug Priority: Major
Reporter: Michael Weber Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS release 5.4 (Final)

Linux xxx 2.6.18-164.10.1.el5 #1 SMP Thu Jan 7 20:00:41 EST 2010 i686 athlon i386 GNU/Linux

PHP 5.3.2 (cli) (built: Mar 4 2010 21:52:46)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

MySQL Server version: 5.1.42-log MySQL Community Server (GPL)


Attachments: Zip Archive doctrine_test.zip    

 Description   

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 Created: 06/Apr/10  Updated: 22/Jun/12

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

Type: Bug Priority: Major
Reporter: MichalKJP Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Symfony 1.4.3, Linux, PostgreSQL, Pgpool II


Attachments: File testcase.tar.bz2    

 Description   

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



 Comments   
Comment by Ludo [ 08/Sep/10 ]

My own Quick Fix for DROP INDEX (into Export class)
Skip Formatter->getIndexName() in Export->dropIndex()
see : http://www.pastie.org/1145916

Comment by MichalKJP [ 08/Sep/10 ]

I already tested this solution and I can confirm that also works for me.

I am afraid that Johnatan spends much time on the new version and did not have time to correct these bugs for the old version. So we still repair migrations manualy.

Comment by James Bell [ 22/Jun/12 ]

We've had this issue for a while - while Ludo's fix does work, there is an SQL injection issue in that the '$name' doesn't get escaped.

You can do this: $name = $this->conn->quoteIdentifier($name); which also steps around the issue for now.

The problem appears to be that the indexes aren't being created with the _idx string on the end when using the migrations. This is probably down to the index creation process rather than the index removal process.





[DC-440] doctrine migration fails with taggable extension Created: 20/Jan/10  Updated: 22/Jan/10

Status: Open
Project: Doctrine 1
Component/s: Extensions, Migrations
Affects Version/s: 1.2.0, 1.2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Robert Gruendler Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

osx 10.6, apache 2, php 5.3, symfony 1.4



 Description   

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' => '', )); }

}



 Comments   
Comment by Robert Gruendler [ 22/Jan/10 ]

i think i found the reason for this. The sfDoctrineGenerateMigrationsDiffTask seems to build it's diff from yml schema files:

protected function execute()....

$this->callDoctrineCli('generate-migrations-diff', array(
'yaml_schema_path' => $this->prepareSchemaFile($config['yaml_schema_path']),
));

The task does not know anything about the models in the doctrine_extensions folder, and there are no yaml files for their
schema, so symfony migration tasks won't work with extensions.

It would be great if this would be mentioned somewhere in the docs of the extensions.





[DC-383] Migrations not respecting ATTR_TBLNAME_FORMAT Created: 23/Dec/09  Updated: 28/May/10

Status: Open
Project: Doctrine 1
Component/s: Attributes, Migrations
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Karma Dordrak (Drak) Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Debian 5, Apache 2, PHP 5.2.9, MySQL 5.1


Attachments: Text File migration_table_prefix_doctrine_1.2.patch    

 Description   

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.



 Comments   
Comment by Erik Wegner [ 28/May/10 ]

Simple patch to set the table name inside constructor





[DC-1028] Doctrine Migrate functions for current version and for creating the migrations table Created: 16/Aug/11  Updated: 17/Apr/14

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

Type: Improvement Priority: Minor
Reporter: Stephen Ostrow Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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-803] Syntax error in MySQL migration to drop constraint (patch supplied) Created: 29/Jul/10  Updated: 29/Jul/10

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

Type: Bug Priority: Minor
Reporter: Gavin Davies Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Debian, PHP 5.3.2, MySQL


Attachments: Text File SyntaxFixForMySQLDropConstraintInExport.patch    

 Description   

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.



 Comments   
Comment by Gavin Davies [ 29/Jul/10 ]

fixing syntax





[DC-767] Doctrine_Migration_Builder::generateMigrationClass() improperly loads migration class Created: 25/Jun/10  Updated: 25/Jun/10

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

Type: Bug Priority: Minor
Reporter: Brandon Franzke Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

N/A



 Description   

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.






[DC-597] symfony doctrine:generate-migrations-diff task doesn't take attributes into account Created: 23/Mar/10  Updated: 08/Jun/10

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

Type: Bug Priority: Minor
Reporter: Bob Stremel Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows 7, Apache 2.2.14, PHP 5.2.11, MySQL 5.0.86



 Description   

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 Created: 12/Feb/10  Updated: 13/Feb/10

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

Type: New Feature Priority: Minor
Reporter: Stephen Ostrow Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

All



 Description   

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.






Generated at Wed Oct 01 22:30:55 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.