[PR #8347] Add doctrine/dbal 3 support #10940

New Issue

admin · 2026-01-22T16:09:10+01:00

admin commented

2026-01-22 16:09:10 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/8347

State: closed
Merged: No

Hi all,

This is a first attempt into having DBAL 3 support on the 2.x ORM branches. There are some things that should we discussed, namely:

Some Platforms do no longer exist on DBAL (PostgreSqlPlatfrom, PostgreSql91Platfrom, PostgreSql92Platfrom, SQLServerPlatform, SQLServer2005Platform, SQLServer2008Platform). As DBAL is most of the times fetched as a dependency of ORM this can be a problem if someone still relies on those platforms. Not sure if this should be considered a BC-break, and hence DBAL 3 would not be possible on ORM 2. Some tests that relied on those platforms have then changed.
Some methods that the ORM uses are no longer present on DBAL 3, namely AbstractPlatform::prefersSequences(), AbstractPlatform::getSQLResultCasing() and AbstractPlatform::fixSchemaElementName(). For prefersSequences I think I have found an acceptable workaround that should not break anything. For getSQLResultCasing I have created a new SQLResultCaser class to do it, same with fixSchemaElementName() and a new SchemaElementNameFixer. See the discussion with @morozov on https://github.com/doctrine/dbal/pull/4229
Should we trigger deprecation warnings somewhere?

Tests pass with both DBAL 2 and DBAL 3. I have raised the minimum DBAL version to 2.12.

**Original Pull Request:** https://github.com/doctrine/orm/pull/8347 **State:** closed **Merged:** No --- Hi all, This is a first attempt into having DBAL 3 support on the 2.x ORM branches. There are some things that should we discussed, namely: - Some Platforms do no longer exist on DBAL (`PostgreSqlPlatfrom`, `PostgreSql91Platfrom`, `PostgreSql92Platfrom`, `SQLServerPlatform`, `SQLServer2005Platform`, `SQLServer2008Platform`). As DBAL is most of the times fetched as a dependency of ORM this can be a problem if someone still relies on those platforms. Not sure if this should be considered a BC-break, and hence DBAL 3 would not be possible on ORM 2. Some tests that relied on those platforms have then changed. - Some methods that the ORM uses are no longer present on DBAL 3, namely `AbstractPlatform::prefersSequences()`, `AbstractPlatform::getSQLResultCasing()` and `AbstractPlatform::fixSchemaElementName()`. For `prefersSequences` I think I have found an acceptable workaround that should not break anything. For `getSQLResultCasing` I have created a new `SQLResultCaser` class to do it, same with `fixSchemaElementName()` and a new `SchemaElementNameFixer`. See the discussion with @morozov on https://github.com/doctrine/dbal/pull/4229 - Should we trigger deprecation warnings somewhere? Tests pass with both DBAL 2 and DBAL 3. I have raised the minimum DBAL version to 2.12.

admin added the pull-request label 2026-01-22 16:09:10 +01:00

admin closed this issue

2026-01-22 16:09:10 +01:00

admin referenced this issue

2026-01-22 16:14:55 +01:00

[PR #10940] tests[ORMSetupTest]: testCacheNamespaceShouldBeGeneratedForApcu requires enabled apc #12708

Sign in to join this conversation.