-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Closed
Labels
Description
Hello,
I think there is a problem when providing the server_version
parameter.
when having a server_version
set to 10.2.12
, the bug discussed here is still present. (it generates endless migrations diff)
When removing the server_version
parameter, it works as excepted.
doctrine:
dbal:
default_connection: default
connections:
default:
server_version: "%database_server_version%" // << resolves to 10.2.12
We also tried
doctrine:
dbal:
default_connection: default
connections:
default:
server_version: 10.2.12
Could it be that the excepted version is something else than 10.2.x ?
dstensnes
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
lcobucci commentedon Jan 22, 2018
@tristanbes could you please send us a failing test case that reproduces that behaviour? It would help us a lot to identify and fix the issue you're describing.
tristanbes commentedon Jan 22, 2018
ping @Kocal
Kocal commentedon Jan 22, 2018
Hey!
I re-used the testing project made here by @Bukashk0zzz, in 3 different versions:
server_version
'10.2.12'
(quotes)10.2.12
(no quotes)server_version
(commented)Ocramius commentedon Jan 24, 2018
Kocal commentedon Jan 28, 2018
Hey,
I isolated the project from Symfony and this is what I found:
serverVersion
'10.2.12'
(quotes)10.2.12
(no quotes)serverVersion
(commented)It seems that outside Symfony, 3rd and 4nd versions are failing ... 🤔EDIT: I forgotten to use
doctrine/dbal:dev-master
, now all versions are working 😨EDIT 2: I renamed
server_version
toserverVersion
(thanks @nick4fake). Now the first and second tests are failing, and it's not really coherent with previous results inside Symfony context... 😞tristanbes commentedon Jan 28, 2018
@Kocal you didn't require
doctrine/dbal master
, (see https://github.com/Kocal/project-doctrine-migrations-and-mariadb-issues/blob/master/composer.json#L3)Kocal commentedon Jan 28, 2018
Oh, I forgotten it again ... thx 👍
nick4fake commentedon Jan 28, 2018
Still an issue with doctrine/dbal master.
Setting server_version to any version returns update bug back
Kocal commentedon Jan 28, 2018
Inside or oustide Symfony context?
nick4fake commentedon Jan 28, 2018
Inside Symfony context with bitnami/mariadb:10.2.12-r0 image. Commenting out version helps, but this is not something we can do (as doctrine tries to connect to db on cache:clear)
nick4fake commentedon Jan 28, 2018
@Kocal BTW, it seems you are using "server_version" parameter in your test, but isn't the correct naming serverVersion?
Doctrine bundle in symfony translates server_version to serverVersion.
Kocal commentedon Jan 28, 2018
Oh, you are right, I wasn't aware about this.
I'm working on it 😄
Kocal commentedon Jan 28, 2018
Updated, now it's when I don't specify
serverVersion
that everything works26 remaining items
violuke commentedon Apr 16, 2018
For me on doctrine v2.6.1 (with Symfony) we need a
server_version
of10.2.14-mariadb
(so themariadb
bit at the end, not the beginning. I hope this helps others.tristanbes commentedon Apr 16, 2018
well it doesn't seem to make a difference since the condition is
$mariadb = false !== stripos($version, 'mariadb');
So as soon as mariadb is detected, it should be ok ?
violuke commentedon Apr 16, 2018
When I use it with
mariadb-
at the start, I get the following, but with it at the end it seems to be ok.Thanks
tristanbes commentedon Apr 16, 2018
and are you sure you are using
doctrine/dbal
>=2.7 @violukeWhat does tell you
composer show doctrine/dbal
?violuke commentedon Apr 17, 2018
@tristanbes, no I'm using 2.6.1 of doctrine/orm and 2.6.3 of doctrine/dbal. I said I was on 2.6 originally. Does this change from 2.6 to 2.7?
Thanks
tristanbes commentedon Apr 17, 2018
Yes, MariaDB is only supported with dbal >= 2.7
mrtnzagustin commentedon Mar 12, 2020
I have problems with endless migration files when dbal is not detecting nulls. The problem is with doctrine/dbal 2.9.2 and mariadb 1.3.x and 1.4.x. Tried everything
w3sami commentedon Apr 22, 2020
I'm too still (for years now) having the same issue. current versions
dbal 2.10.2
10.4.12-mariadb
symfony 5
mrtnzagustin commentedon Apr 22, 2020
@w3sami we make a deep analysis and we were having problems with "default" values sintax in our annotations, make sure to double check that!
w3sami commentedon Apr 22, 2020
Hi, thanks for the reply. I'm not using any default values. Probles are in every field, even in relations eg.
/**
* @Orm\OneToOne(targetEntity="App\Entity\Menu", inversedBy="Page")
* @Orm\JoinColumn(name="menu_id", referencedColumnName="id", unique=true, onDelete="CASCADE")
*/
private $Menu;
for this i always get
ALTER TABLE page CHANGE menu_id menu_id INT DEFAULT NULL
due to the NULL != 'NULL' bug.
Are you saying, you somehow went around the problem by adding default values to your entity annotations?
mrtnzagustin commentedon Apr 22, 2020
Exactly, we had problems with default '0' vs 0 in booleans for example, and we focus to explicity add defaults values until fix the issue. It's a workaround, but it better than having buggy migrations outputs.
w3sami commentedon Apr 22, 2020
yes, sadly it does not help for the join column as the option is to add nullable=flase, which yields the same results, as it is the default already.
BUT! I actually ran the suggested var_dump(get_class($connection->getDriver()), get_class($connection->getDatabasePlatform())); from above, and found out, that it tried to use mysql5.7, even tho I had setted the config. The problem was, that in the default symfony configs, the server version is in the .env file! I cleared that up, and now it works just fine :)
github-actions commentedon Jul 29, 2022
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.