Skip to content
This repository

Update schema always results in same query #103

Closed
roelveldhuizen opened this Issue June 19, 2012 · 11 comments

8 participants

Roel Veldhuizen Thomas Matteo Giachino simon chrzanowski Sven Loth Tom Young Sterin Grigoriy Nate Lenart
Roel Veldhuizen

When I run php app\console doctrine:schema:update --force this wil always result in the same query and other updates are ommited.

ALTER TABLE fos_user_user CHANGE facebook_data facebook_data LONGTEXT DEFAULT NU
LL, CHANGE twitter_data twitter_data LONGTEXT DEFAULT NULL, CHANGE gplus_data gp
lus_data LONGTEXT DEFAULT NULL;
ALTER TABLE notification__message CHANGE body body LONGTEXT NOT NULL

Also, according to the output, the queries are executed successfully.

Matteo Giachino

no news about this?
Maybe is something related to the JsonType that is bound to all the columns that continue to receive updates?
Does anyone have the same problem with custom doctrine types?

Roel Veldhuizen

No, new news, still have the issue.

Matteo Giachino

@rande any ideas on how to solve this problem?

simon chrzanowski

same here... :-(

Thomas
Owner

This is not an issue with this bundle, you shouldn't rely on this command to update the database. Always use migration.

Thomas rande closed this August 05, 2012
Sven Loth

Same problem here with doctrine migration, the query from above will appear whenever you you diff your code with the database, even after a successful migration.

Matteo Giachino

I tried to dig the problem, but didn't find any solutions yet

Tom Young

Any solution for this?

Nate Lenart

I'm having the same problem, with and without migrations. I realize this discussion is on the SonataUserBundle, but I'm not using that and am still having this issue, leading me to believe the problem may be buried somewhere in core:

$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE table1 CHANGE external_data external_data LONGTEXT DEFAULT NULL;
ALTER TABLE table2 CHANGE supplemental supplemental LONGTEXT DEFAULT NULL;
ALTER TABLE table3 CHANGE supplemental supplemental LONGTEXT DEFAULT NULL;

My Types are registered in the boot() function of my bundle class. As slot mentioned above, I can keep generating and running migrations endlessly and the diff will always produce the above result. Looking at the database directly, I can see the columns are defined correctly.

Supplemental info
Not sure if it's helpful at all, but I originally implemented the custom types in a project using Kohana + Doctrine and am migrating over to Symfony. I previously added the Types and registered the mapping in the Kohana bootstrap. I could use the Doctrine console (which relies on the Symfony console, to an extent) to update the database and that works fine:

$ doctrine orm:schema-tool:update --dump-sql
Nothing to update - your database is already in sync with the current entity metadata.

(Note that "doctrine" above is a bash alias for this: $ /path/to/doctrine/console connection DOCROOT APPPATH)

I'm also interested to see that both of our changes are using "LONGTEXT DEFAULT NULL". Correlation?

I'm assuming this ticket was closed because it doesn't actually apply to SonataUserBundle, but did it get moved anywhere else? Seems like there are several of us still looking for solutions.

Nate Lenart

UPDATE

Looks like the issue was in DoctrineBundle: (see doctrine/DoctrineBundle#6 and doctrine/DoctrineBundle#21)

I had originally placed code in the boot() function of my bundle, as mentioned:

public function boot()
{
    // get necessary variables                                               
    $em = $this->container->get('doctrine.orm.entity_manager');
    $platform = $em->getConnection()->getDatabasePlatform();

    // add new database "column types" to Doctrine ORM
    Type::addType('my_custom_type', 'Acme\DemoBundle\Types\MyCustomType');

    // register the mapping of the type to Doctrine DBAL
    $platform->registerDoctrineTypeMapping('my_custom_type', 'my_custom_type');
}

It turns out this isn't enough; you need to add the following to register comments in the database as well:

// mark the custom type as commented; helps schema-tool generates diffs
$platform->markDoctrineTypeCommented('my_custom_type');

But it seems the preferred Symfony way of registering custom types is now as follows (see http://symfony.com/doc/current/cookbook/doctrine/dbal.html#registering-custom-mapping-types):

doctrine:
    dbal:
        # Doctrine ORM type mapping
        types:
            my_custom_type: Acme\DemoBundle\Types\MyCustomType
        # Doctrine DBAL type mapping (this is crucial, for some reason)
        mapping_types:
            my_custom_type: my_custom_type

And as it turns out,

my_custom_type: Acme\DemoBundle\Types\MyCustomType

is actually a shortcut for:

my_custom_type:
    class: Acme\DemoBundle\Types\MyCustomType
    commented: true

After that fix, the first time I see:

$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE table1 CHANGE external_data external_data LONGTEXT DEFAULT NULL COMMENT '(DC2Type:external_data)';
ALTER TABLE table2 CHANGE supplemental supplemental LONGTEXT DEFAULT NULL COMMENT '(DC2Type:supplemental)';
ALTER TABLE table3 CHANGE supplemental supplemental LONGTEXT DEFAULT NULL COMMENT '(DC2Type:supplemental)'

And the second time I see:

$ php app/console doctrine:schema:update --dump-sql
Nothing to update - your database is already in sync with the current entity metadata.

Sorry these posts were long (and sort of in the wrong place) but I hope it will help Googlers like me trying to aggregate solutions from different places.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.