[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

PostgreSQL 9.0


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

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.



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

Generated at Tue Dec 01 01:05:26 EST 2015 using JIRA 6.4.10#64025-sha1:5b8b74079161cd76a20ab66dda52747ee6701bd6.