Incorrect migrations with NULL fields on MariaDB 10.3

[joshhornby]

Bug Report

Q	A
BC Break	unsure
Version	2.8

Summary

When running a doctrine:migrations:diff on MariaDB 10.3.5 there is an issue with NULL fields being included in each subsequent migration diff.

How to reproduce

https://github.com/joshhornby/doctrine-mariadb-migrations-example

Follow the example in the README of the above repo. Looking in the migrations folder https://github.com/joshhornby/doctrine-mariadb-migrations-example/tree/master/src/Migrations the second migration should be empty, but doctrine thinks it needs to update the $test field. If this field was nullable = false then the second migration would be empty.

-> CREATE TABLE example (id INT NOT NULL, test VARCHAR(50) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB

  ++ migrated (0.4s)

  ++ migrating 20181005201822

     -> ALTER TABLE example CHANGE test test VARCHAR(50) DEFAULT NULL

Expected behaviour

The following migrations should not contain any changes to the test column.

[jwage]

This issue belongs in the doctrine/dbal repository.

[joshhornby]

@jwage This is the doctrine/dbal repository?

[joshhornby]

@jwage Can this be reopened as I believe this is the correct repository for this issue? If it isn't please can you link me to the correct place?

[Majkl578]

MariaDB 10.3 is not yet supported, will be as of DBAL 2.9 - see #3283.
Your issue seems relevant to the BC Break in MariaDB 10.2.7 (doctrine/orm#6565), this should already be fixed by #2825 (as of DBAL 2.7) when you configure platform version correctly.

[jwage]

Sorry, I'm an idiot. I misread the repository.

[svycka]

MariaDB 10.3 is not yet supported, will be as of DBAL 2.9 - see #3283.

@Majkl578 are you sure this is fixed? I tried with "doctrine/dbal": "2.9.x-dev as 2.8.0", and it does not work even with mariadb 10.2.7

[Ocramius]

@svycka possibly new test scenario needed, as something else may be missing then.

[svycka]

Sorry, my fault I had hardcoded database version in config. now with a correct version works better but still wrong.

doctrine/dbal:2.9.x-dev
maraidb:10.2.14 and mariadb:10.3.10

ALTER TABLE warehouse_fuel_purchase CHANGE fuelType fuelType INT DEFAULT 1 NOT NULL;
ALTER TABLE warehouse_fuel_filling CHANGE fuelType fuelType INT DEFAULT 1 NOT NULL;
ALTER TABLE warehouse_fuel_storage CHANGE fuelType fuelType INT DEFAULT 1 NOT NULL;

doctrine/dbal:2.8.0
maraidb:10.2.14 and mariadb:10.3.10

[OK] Nothing to update - your database is already in sync with the current entity metadata.       

looks like 2.8.0 works better because DEFAULT 1 is already set in the database and should not reappear

[svycka]

@Ocramius I have found problem #3349 not related with this so created new issue

[MartinMa]

I just ran into the same issue!

@jwage Could you please re-open this issue? It is not fixed yet. We are at doctrine/dbal: "2.9.2" and MariaDB 10.3 should be officially supported by now (as per @Majkl578).

From what @svycka has been revealing, this seems to be a regression anyway (because it already worked with dbal:2.8.0).

[Ocramius]

Please create a new issue with a test case, @MartinMa

[MartinMa]

Apologies, seems to be fixed in v2.9.2 with this commit 4389a25. For anyone else running into this problem. Make sure to use the correct doctrine.dbal.server_version in doctrine.yaml. For me it had to be server_version: 'mariadb-10.3.17'.

[friedrichroell]

Apologies, seems to be fixed in v2.9.2 with this commit 4389a25. For anyone else running into this problem. Make sure to use the correct doctrine.dbal.server_version in doctrine.yaml. For me it had to be server_version: 'mariadb-10.3.17'.

for symfony flex versions the version in the .env file if set, will overwrite these settings so remember to use the correct version there. e.g.:
DATABASE_URL=mysql://user:pw@127.0.0.1:3306/db_name?serverVersion=mariadb-10.4.11

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.