Upgrade From 2.x to 3.0.0

[tarlepp]

Currently UPGRADE.md doesn't mention that ./bin/console doctrine:migrations:sync-metadata-storage command should be executed - is there some reason for this or is the documention just missing this part?

[corlanalexandru]

For me, it doesn't work to run the command php bin/console doctrine:migrations:sync-metadata-storage

[tarlepp]

For me, it doesn't work to run the command php bin/console doctrine:migrations:sync-metadata-storage

weird, that did the trick for my application - do you get some error from that command?

[corlanalexandru]

I updated the configuration file
doctrine_migrations:
migrations_paths:
'DoctrineMigrations': '%kernel.project_dir%/src/Migrations'
storage:
table_storage:
table_name: 'migration_versions'
version_column_name: 'version'
version_column_length: 1024
executed_at_column_name: 'executed_at'

[corlanalexandru]

But i get the same error to run the sync-metadata-storage

[corlanalexandru]

Can you share your doctrine_migrations.yaml file?

[tarlepp]

what is the actual error?

[corlanalexandru]

The metadata storage is not up to date, please run the sync-meta
data-storage command to fix this issue.

[tarlepp]

Can you share your doctrine_migrations.yaml file?

sure,

doctrine_migrations:
    migrations_paths:
        'DoctrineMigrations': '%kernel.project_dir%/src/Migrations'
    storage:
        table_storage:
            table_name: 'migration_versions'
            version_column_name: 'version'
            version_column_length: 512
            executed_at_column_name: 'executed_at'

I needed to adjust that version_column_length from 1024 to 512 just because I'm using MySQL 5.7 which have known problem with index sizes.

Also note that you could get more information about that error if you add -vvv option to that command.

[goetas]

@corlanalexandru do you have some custom type mappings on the datetime type?

[corlanalexandru]

I deleted the migration_version table, then i ran php bin/console doctrine:migrations:sync-metadata-storage and when I ran php bin/console doctrine:migrations:migrate i still get the same error

[corlanalexandru]

New
CREATE TABLE migration_versions(versionvarchar(512) COLLATE utf8_unicode_ci NOT NULL,executed_atdatetime DEFAULT NULL,execution_timeint(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
OLD
CREATE TABLEmigration_versions(versionvarchar(14) COLLATE utf8mb4_unicode_ci NOT NULL,executed_at datetime NOT NULL COMMENT '(DC2Type:datetime_immutable)' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

[goetas]

can you please answer to #329 (comment) ?

[corlanalexandru]

can you please answer to #329 (comment) ?

I don't have. All entities were generated from command line with basic types

[goetas]

@tarlepp the doc does not mention that becase if you run just /bin/console doctrine:migrations:migrate, it should be executed automatically. (for the other commands as show/version` that is not the case)

but maybe adding a note on the upgrading guide will no hurt

[tarlepp]

@goetas I'm just thinking people who will migrate their current production application to use this - and specially with use case that there isn't new migration file to run.

[goetas]

@tarlepp who has some CI, and runs bin/console doctrine:migrations:migrate on each deploy, there is nothing to update

[inverse]

When I just tried this I

• Modified my configs are per the documentation.
• Ran the ./bin/console doctrine:migrations:sync-metadata-storage command
• Then trying to run the migrate command and got

 [ERROR] The version "latest" couldn't be reached, you are at version "DoctrineMigrations\Version20200517201357"        

[goetas]

@inverse the wording of that message is misleading, but that just means that you are already at the latest version, it will be improved by doctrine/migrations#988

[tarlepp]

@tarlepp who has some CI, and runs bin/console doctrine:migrations:migrate on each deploy, there is nothing to update

This is something that I didn't know - that I need to run that command. Is there some doc about that?

[inverse]

Okays - so it's not an error - but considering that it returns non 0 that's quite a breaking issue.

Can confirm also that the sync command is not needed - just verified locally

[goetas]

there is --allow-no-migration to have it returning 0

[goetas]

Wasn't the same in 2.x (https://github.com/doctrine/migrations/blob/2.3.x/lib/Doctrine/Migrations/Tools/Console/Command/MigrateCommand.php#L61)?

[inverse]

@goetas the problem is that when you run migrate on 2.x it returns 0 even when there is no migrations to be ran. To me this feels like quite a BC since on CI it'll fail the deployment since the migrations were not deemed success.

malachi@vagrant:/var/www/xxxxx/current$ ./bin/console doctrine:migrations:migrate
                                                              
                    Application Migrations                    
                                                              

WARNING! You are about to execute a database migration that could result in schema changes and data loss. Are you sure you wish to continue? (y/n)yes
No migrations to execute.
malachi@vagrant:/var/www/xxxxx/current$ $?
-bash: 0: command not found

[corlanalexandru]

Any idea ? :D

[tarlepp]

@corlanalexandru you could add that -vvv option to that command and then share that stacktrace of that, it would help to spot the actual issue here.

[corlanalexandru]

[pawellen]

I am running this:
php bin/console make:migration
php bin/console doctrine:migrations:sync-metadata-storage
php bin/console doctrine:migrations:migrate --no-interaction --allow-no-migration

I am getting:

[VincentLanglet]

@goetas the problem is that when you run migrate on 2.x it returns 0 even when there is no migrations to be ran. To me this feels like quite a BC since on CI it'll fail the deployment since the migrations were not deemed success.

I agree.
It took me some time to understand why my deployment wasn't working anymore.

This should be in the upgrade note.

[goetas]

updated doc in doctrine/migrations#993

[goetas]

@pawellen can you please check #329 (comment) ?

[pawellen]

@pawellen can you please check #329 (comment) ?

@goetas I don't have any. Maybe one of those causes problem:
@Orm\Column(type="text", length=4294967292, nullable=true)
@Orm\Table(name="range")

I am not sure if this can help somehow. Those are all my mappings lines: report.txt I don't know what to look for, there is no mention in doc how this new "sync-metadata-storage" command works.

[k00ni]

Maybe its helpful to someone: If you use orm-pack as a normal dependency it will automatically upgrade DoctrineMigrationsBundle from 2.1.x to 3.0, which might lead to an exception because your configuration became "invalid". My mistake

Ref: symfony/orm-pack#24

[LuigiCardamone]

Is there any reason why the suggested value for "version_column_length" is 1024?
Like @tarlepp I had to put 512 to avoid this error on MySql:
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 3072 bytes

[tarlepp]

@tarlepp the doc does not mention that becase if you run just /bin/console doctrine:migrations:migrate, it should be executed automatically. (for the other commands as show/version` that is not the case)

but maybe adding a note on the upgrading guide will no hurt

I think we can close this issue, and continue those other problems with separated issues - so it's easier to keep things together.