Run builds with DBAL 4.0.x-dev

[morozov]

Relevant changes from DBAL 4.0.x:

1. Connection::quote() can only quote strings dbal#3488
2. Add proper types to Doctrine\DBAL\Types namespace. dbal#3569
3. Getting rid of the column name index dbal#3583

TODO:

• Backport what's possible to 2.13.x and rebase: Forward compatibility with DBAL 4 #9730
• Address static analysis issues when testing against DBAL 3.4.x-dev.
• Why do discriminator maps have numeric keys despite their <string,class-string> type? Known issue to be baselined.
• Improve MySQL test suite compatibility with DBAL 4 (Test MySQL DDL using explicit table options #9728).

Improve DBAL upgrade path:

• Get Deprecate AbstractPlatform::getVarcharTypeDeclarationSQL() dbal#5373 merged.
• Get Add runtime deprecations for default string column length dbal#5377 merged.

Next steps:

1. Build with DBAL 4@dev on MySQL and MariaDB #9735.
2. Test the build with ^4@dev on PostgreSQL.
3. Run static analysis with ^4@dev.
4. Bump DBAL version constraint to ^3.4 once it's released.

[morozov]

@derrabus do you have a recommendation on addressing this static analysis issue?

lib/Doctrine/ORM/Persisters/Entity/SingleTablePersister.php:144:44: RedundantCastGivenDocblockType: Redundant cast to string given docblock-provided type

It's related to this bullet point:

Why do discriminator maps have numeric keys despite their <string,class-string> type?

One of the non-string occurrences is addressed by adding this:

orm/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php

Line 90 in bdf997a

unset($classAnnotations[$key]);

But there are more.

[derrabus]

@derrabus do you have a recommendation on addressing this static analysis issue?

This is a known issue with discriminator maps. Baseline it for now, fixing it is out of scope for this PR.

[morozov]

Would it be acceptable to bump this version constraint temporarily (we can pin it to a specific commit)?

I plan to add a couple more upgrade path improvements to the DBAL 3.4 (see the description). Since they are not yet released, if we don't bump the constraint, we will either have to force the release in order to avoid the dependency of the dev ORM on dev DBAL, or we will have to refrain from merging all the changes related to the DBAL 4 until they are implemented in full and the scope of the upgrade path improvements is fully defined.

I believe this change is acceptable since it's unlikely that ORM 3 will be released before DBAL 3.4. Even if this happens, we can release DBAL 3.4 right before that.

[greg0ire]

I think it's fine, as you say we can still force publish 3.4 in the unlikely event we want to publish ORM 3 before it is ready.

[derrabus]

This is fine, but let's use this constraint instead:

Suggested change

	"doctrine/dbal": "^3.4.x-dev",
	"doctrine/dbal": "^3.4@dev",

[morozov]

Yeah, we can use that. How is it better than the original constraint?

[derrabus]

It's consitent with what we usually use in those situations.

[greg0ire]

I think it's fine, as you say we can still force publish 3.4 in the unlikely event we want to publish ORM 3 before it is ready.

[greg0ire]

This should be fixed up into b291c4e

[derrabus]

We want the 2.x series to run deprecation-free with DBAL 3.x. This PR seems to prepare the ORM for some deprecations coming with DBAL 3.4.0. Can we backport parts of this PR to 2.13.x?

[morozov]

Yeah, about half of these commits could be backported to 2.13. Even though some of them wouldn't address runtime deprecations, they would set an example of writing code compatible with DBAL 4 (e.g. 9f0ff98, 96b1c37, 99aa247).

I can start with backporting and once they are merged back up, we can continue here. In the meantime, I can address any issues regarding the code changes.

[derrabus]

Sounds good.