[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






[DBAL-1085] Custom Type Compare Fails To Generate Correct Migrations Created: 19/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0, 2.1, 2.2, 2.3, 2.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Vanheuverzwijn Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: migrations
Environment:

Everywhere



 Description   

// From doctrine 2.1
public function diffColumn(Column $column1, Column $column2)
{
$changedProperties = array();
if ( $column1->getType() != $column2->getType() )

{ $changedProperties[] = 'type'; }

...
}
The $column1->getType() will return the underlying platform object but the $column2->getType() will return the custom object type.

Because of the way the php compare function works, a custom type will always generate a changed property over the type of a column.

http://stackoverflow.com/questions/26964367/symfony2-doctrine-custom-types-generating-unneeded-migrations/27557785#27557785



 Comments   
Comment by Steve Müller [ 24/Dec/14 ]

Nicolas Vanheuverzwijn I think you will have to mark your custom type as requiring a SQL comment, otherwise the schema manager cannot distinguish between DateTime type and your custom type because both map to the same native SQL type. See here:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L327-L340

You will have to add the following to your custom type implementation:

/**
 * {@inheritdoc}
 */
public function requiresSQLCommentHint(AbstractPlatform $platform)
{
    return true;
}

Also I think it might be required to give your custom type a distinct name like:

/**
 * {@inheritdoc}
 */
public function getName()
{
    return 'datetime_utc';
}
Comment by Steve Müller [ 24/Dec/14 ]

See also: http://doctrine-orm.readthedocs.org/en/latest/cookbook/custom-mapping-types.html

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Wow, I shall take a look at this. This might be it ! Thanks a lot for your reply.

Comment by Steve Müller [ 24/Dec/14 ]

You're welcome. Can you please report if that fixed your problem so we can closse the issue eventually? Thanks.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Yes sir. The problem I have was that I am using doctrine 2.2. I shall migrate my stuff to doctrine 2.5 and use that feature.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

This feature is implemented in version >=2.3 of Doctrine/DBAL.

Comment by Steve Müller [ 24/Dec/14 ]

Yes. 2.2 is EOL anyways and I think 2.3 is now only getting security fixes so an upgrade to at least 2.4 is highly recommended.





[DBAL-550] Complete/non-overridable event dispatching in DDL methods of AbstractPlatform Created: 22/Jun/13  Updated: 23/Dec/13

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Stéphane Klein Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: migrations, schematool


 Description   

The default implementation provided by the AbstractPlatform class dispatches several events related to schema modifications (create table, change column and so on) and offers the ability to prevent the default behaviour by setting a flag on the dispatched event. However, it appears that some DDL operations aren't covered by this mechanism (foreign keys creation, for example, doesn't seem to be observable). Furthermore, the concrete platforms can override any of these methods, potentially leading to inconsistancies in components that expect those events to be dispatched.

I'm working on a large modular application build on top of Symfony, in which each bundle must have its own migration classes (i.e. migrations on a per bundle basis, not at the application level), possibly with references to other parts of the schema. I used to write those classes manually using the dbal api, but this is tiedous and error-prone, and I'd like to take advantage of the mapping-based schema generation. I found that using the event system and "filtering" ddl operations to keep only the operations related to a given bundle is a clean and easy way to achieve this goal, but the issues I mentionned prevent me to complete the implementation.

I'd be glad to hear your opinion on that topic and, providing you're interested in it, contribute in a way or another to improve the existing code.



 Comments   
Comment by Benjamin Eberlei [ 22/Jun/13 ]

This is not a blocker

Comment by Benjamin Eberlei [ 22/Jun/13 ]

The DBAL event system is not in its best shape and definately could use some improvement. Your easiest way however would be to hook the process of generating the whole schema, and then dropping tables from those two to only contain the ones you are interested in.

Comment by Stéphane Klein [ 23/Jun/13 ]

That's indeed the simplest solution. Thanks a lot for your answer.

Comment by Steve Müller [ 23/Dec/13 ]

Benjamin Eberlei Is there anything to do here? Should the missing events be added or is that not necessary?





Generated at Sat Feb 28 17:29:14 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.