False collation on current 2.6.x-dev 89b7ed6 version

[alexander-schranz]

Bug Report

I'm trying to find out why my table schema is not correclty utf8mb4 after using @dev dependencies.

Q	A
Version	2.6.x-dev 89b7ed6
MySQL	5.7.37 / 8.0.27
PHP	8.1.2

Summary

On current stable version all is correctly in my database utf8mb4. I have no collation set manually in doctrine.yaml. But after ugprading to @dev version the collation is created not longer as utf8mb4 which was the default since I think dbal 3 for mysql.

Current behaviour

The schema has a strange mixed collation now:

How to reproduce

composer create-project sulu/skeleton
cd skeleton
composer config minimum-stability dev
composer update # installs doctrine-bundle 2.6.x-dev 89b7ed6
docker compose up
bin/console sulu:build dev
# check database e.g. `ac_activities` table

Expected behaviour

On 2.5.6 all works like expected:

Maybe related to #1478 /cc @greg0ire

[ostrolucky]

I don't think we changed anything in doctrine-bundle that could have affected this. You should find first which dependency caused this (most likely dbal).

[alexander-schranz]

@ostrolucky already tested that. If I'm downgrading only doctrine-bundle to 2.5.6 and all other dependencies are unchanged the collation is correctly created.

The first run is with 2.6.x-dev 89b7ed6
The second one with 2.5.6

all other dependencies are the same:

[dmaicher]

Strange... I also cannot spot anything that would explain this issue in the diff

[alexander-schranz]

I would think that maybe doctrine/dbal still requires both to be define collate and collation:

Now only the new option is defined: f1423b2#diff-df25e842a7fa5aa6cfb5504f8a15789ce8988d620bcd4ace17d2000222feb507

But need to test that out if I added the other option if it works then.

Manually defining the default table options did atleast use the utf8mb4 this way did create the correct schema:

doctrine:
    dbal:
        default_table_options:
            charset: utf8mb4
            collate: utf8mb4_unicode_ci

So it need have todo with the table default options.

[greg0ire]

Do you have any charset option defined in your database_url as well?

Maybe related to #1478 /cc @greg0ire

It does look related, maybe you can try pinning to a commit before and after my PR, and see what happens?

[alexander-schranz]

@greg0ire we have nothing define also not in the doctrine.yaml:

https://github.com/sulu/skeleton/blob/2.x/config/packages/doctrine.yaml
https://github.com/sulu/skeleton/blob/2cb154888d20fd71022b8636a46015649cf05166/.env#L44

Defining it is just the current workaround.

[greg0ire]

Here is why I asked: symfony/recipes#1059

Are you going through this code path:

DoctrineBundle/ConnectionFactory.php

Lines 85 to 87 in 6e578fd

	} else {
	$params['charset'] = 'utf8';
	}

?

[alexander-schranz]

On commit f1423b2a640b6ac545b6e0c02575427a4dc1e9dc (2.5.6) it works and on next commit 1b75234e580e1682a57468d6af7ac5c9d4688d0c it fails:

commit 1b75234e580e1682a57468d6af7ac5c9d4688d0c (HEAD)
Merge: 543ec0f f1423b2
Author: Grégoire Paris <postmaster@greg0ire.fr>
Date:   Sun Feb 13 22:48:32 2022 +0100

    Merge pull request #1477 from doctrine/2.5.x

    Merge 2.5.x up into 2.6.x

1b75234

[alexander-schranz]

Its strange on 2.5.6 the $driver is: Doctrine\DBAL\Driver\PDO\MySQL\Driver
on that commit $driver is: Doctrine\DBAL\Logging\Driver

[alexander-schranz]

That is why on that commit the utf8mb4 part is skipt.

[alexander-schranz]

Changing:

-                if ($driver instanceof AbstractMySQLDriver) {
+                if ($driver->getDatabasePlatform() instanceof AbstractMySQLPlatform) {

Seems to work.

[greg0ire]

I think what broke this was #1456

[alexander-schranz]

Yes I tested the 2.5.x on that works and 2.6.x does not work. I also think it related to the logging middleware handling. But could not yet found a solution for it which does not make any tests failing.

[alexander-schranz]

We got a report from a doctrine-bundle 2.5.6 project which did have the same problem only on production. After debugging I have found out on production there is Sentry enabled which is also decorating the Driver and they end so in the same scenario with the tracingdriver of sentry:

https://github.com/getsentry/sentry-symfony/blob/master/src/Tracing/Doctrine/DBAL/TracingDriverForV3.php

[greg0ire]

One more reason to strongly deprecate this codepath.

[alexander-schranz]

@greg0ire time to bring back ensure production config command which requires than serverVersion and charset being set ;)

[Mika56]

Confirming we're only seeing this issue when SentryBundle is enabled.
Workaround is enabling SentryBundle only in prod in your config/bundles.php file

[alexander-schranz]

@Mika56 I recommend setting the charset on your server in the DATABASE_URL:

https://github.com/symfony/recipes/pull/1059/files#diff-12d522d4ed600c8eef096cb3ea3fcaa411fe6f3ba6aeb2039f822e7e57250727L14

[Mika56]

@alexander-schranz That did not fix the problem for us. Our migrations were trying to MODIFY every string column in the down() part