Orm: MariaDB 10.2.x bug with symfony (solved)

[remoteclient]

Bug Report

| Q | A
|------------ | ------
| BC Break | yes/no
| Version | x.y.z

Summary

According to this issue: issue 6565 the bug exists in MariaDB 10.2.14 and 10.2.15

Current behavior

Concretely, for Doctrine, schema update just gone crazy and want to update every column with NULL default because 'NULL' is return by MariaDB instead of NULL.

How to reproduce

Set a 'DEFAULT NULL' statement in a entities column definition.
doctrine:schema:update --dump-sql shows the queries to execute
doctrine:schema:update --force execute the queries
run doctrine:schema:update --dump-sql again -> all queries with DEFAULT NULL will show up although they where already executed

Expected behavior

Don't show the queries again.

[belgattitude]

@remoteclient

I believe it's a config issue... two questions:

1. Are you using 'server_version' in your config ? If yes, it will disable autodetection (one query less) but must be written with patch version.

doctrine:
    dbal:
        driver: 'pdo_mysql'
        server_version: '10.2.7'
        charset: utf8mb4
        default_table_options:
            charset: utf8mb4
collate: utf8mb4_unicode_ci

see also https://github.com/belgattitude/dbal-test/blob/doctrine2/6790/config/packages/doctrine.yaml#L12

1. Did you test any version between 10.2.7 and 10.2.14 too ? Does it suddently appeared in 10.2.14 ?

[belgattitude]

Note also, that you seems to not be the only one... But unfortunately I could not reproduce, see the thread here:

https://github.com/doctrine/doctrine2/issues/6790#issuecomment-385252050

I've also made a testcase:

see the repo here: https://github.com/belgattitude/dbal-test/tree/doctrine2/6790
Success travis build: https://travis-ci.org/belgattitude/dbal-test/builds/372692997

Feel free to dig more. I don't say there's no bug but could not reproduce yet...

[remoteclient]

@belgattitude
First of all thank you for your response. I had this in my config which came automatically with a new fresh install of symfony 4.1:
server_version: '10.2'
I commented this out. After a cache:clear the issue is gone.

So thank you very much for your help. Maybe the server_version shouldn't be there by default as it confuses a lot with this error.

[belgattitude]

@remoteclient

Yes if you want to set up the server_version param. BTW, it's a good idea (we don't need to detect the server version every time), please use:

server_version: '10.2.7' (or greater) instead of server_version: '10.2'

EDIT I was wrong, see later in the thread: server_version: 'mariadb-10.2.7' is correct.

Few questions:

• Would be awesome if you report the bug in symfony. The reason why '10.2.7', is that the schema change appeared in mariadb 10.2.7... It's a breaking change but hidden in a patch version.

  When I made to P/R to support mariadb, there was no clear consensus: do we set 10.2.7 as version or 10.2 ?. We chose 10.2.7... and it's not intuitive at all. I really regret afterwards.

• Can you change the title of the issue ?

  • as an example: MariaDB 10.2.x bug with symfony (solved) - or anything that could help people to look at the solution.

Then feel free to close the bug whenever you're sure it's working.

[remoteclient]

@belgattitude

• Yes, of course. I changed the title
• I tried both: server_version: '10.2.7' and server_version: '10.2.15'' and cleared the cache with no success. The queries always reappeared with --dump-sql
• only commenting out the server_version: '10.2.7' this issue was solved for me.

[belgattitude]

@remoteclient

Great... at least we know where to debug... I saw those issues too

https://github.com/doctrine/dbal/issues/3110
https://github.com/symfony/symfony-docs/pull/9547

Look the correct answer is :

server_version: 'mariadb-10.2.7' (must include prefix mariadb, in case mysql reach 10.2.7+ ;)

Anyway thanks for reporting and testing...

[remoteclient]

@belgattitude
Yes, this seems to work. I used server_version: 'mariadb-10.2.15' with success.
Thank you for your investigations and help. I will close this issue as it is solved by using the right server version string.

[nicolaskern]

Hi,

I still have the problem with server_version: 'mariadb-10.3.7', but only with DATETIME :

ALTER TABLE mytable CHANGE myfield myfield DATETIME NOT NULL;

However, no problem anymore for other field types.

Thanks,
Nicolas

[luigif]

Same problem with server_version: 'mariadb-10.2.17' and STRING.
Entity is annotated as:

@ORM\Column(name="token", type="string", length=255, nullable=false)

and

ALTER TABLE translations CHANGE token token VARCHAR(255) NOT NULL;

keeps showing up, but all other NULL fields are correctly managed.

[Bast1onCZ]

Managed to solve by fixing the server_version to my current 10.4.11-MariaDB (as told).

Moreover, when the config parameter server_version was removed, the bug was fixed as well.