[TMP] IBX-12043: Upgraded to Doctrine DBAL 4

[ViniTou]

🎫 Issue	IBX-12043

Related PRs:

• IBX-12043: Upgraded to Doctrine DBAL 4 doctrine-schema#45 (must merge first)
• ibexa/installer dbal-4-upgrade

Important

composer.json carries a [TMP] pointer "ibexa/doctrine-schema": "dev-dbal-4-upgrade as 6.0.x-dev" so this branch can resolve the unreleased schema package. It must be reverted to ~6.0.x-dev once doctrine-schema#45 merges, before this PR is mergeable.

Description:

Stage 3 of the staged Doctrine upgrade (stages 1 and 2 — DBAL 3 cleanup and ORM 3 — already shipped under IBX-12043). ibexa/core and ibexa/doctrine-schema are the two packages pinning doctrine/dbal to 3.x, so both have to move for anything downstream to follow. The constraint goes straight to ^4.4.4 rather than widening.

Most of the diff is the mechanical consequence of four DBAL 4 changes: ParameterType/ArrayParameterType became enums (so the remaining legacy PDO::PARAM_* constants are gone, and array_unique() over them needs SORT_REGULAR), ExpressionBuilder and join conditions are string-only, QueryBuilder::select()/addSelect() became variadic, and QueryBuilder::execute(), Statement::execute(), Result::fetch(), getQueryPart() and update()'s alias parameter were removed.

The part worth a reviewer's attention is platform handling. DBAL 4 removed the platform connection parameter, and DoctrineBundle deprecated its platform_service equivalent in 2.9 for the same reason. This is silent: the connection still accepts and echoes the parameter but returns the stock platform, so SqliteDbPlatform's schema-generation behaviour — notably keeping composite primary keys on tables SQLite cannot express with AUTOINCREMENT — was being dropped without any error. Rather than reinstating the removed behaviour behind a driver middleware, DDL-generating call sites now resolve the Ibexa platform explicitly through the existing DbPlatformFactory, which keeps the choice visible at the point of use. CoreInstaller therefore takes DbPlatformFactoryInterface as a required constructor argument, and DatabasePlatformResolver/DatabasePlatformName move down to ibexa/doctrine-schema, which owns the DBAL abstraction and which ibexa/core depends on.

Two latent bugs surfaced on the way: updateAlwaysAvailableFlag() compared executeQuery()'s Result against 0 (always false — it needed executeStatement()), and the data_float* columns bound with a null parameter type that DBAL 4 rejects outright.

Note that DBAL 4.4 deprecates declaring an auto-increment column inside a composite primary key, which ibexa_content_type, ibexa_content_type_field_definition and ibexa_content_field all do. That is a schema design question well beyond this upgrade and is left as-is.

For QA:

Schema installation and the legacy storage/search gateways are the surfaces touched. Worth verifying a fresh install and a reinstall over an existing schema on MySQL, MariaDB and PostgreSQL, since SQLite is the only backend exercised by the automated suites here.

Documentation:

N/A

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.7% Duplication on New Code

See analysis details on SonarQube Cloud