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

Generated at Fri Jul 25 22:20:26 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.