Add MySQL 8.4 support and fix compatibility problem

[mivancic]

MySQL 8.0 reaches End of Life in April 2026. This fix allows upgrading to MySQL 8.4.8 with existing database schemas without breaking Elasticsearch product indexing.

Problem

On MySQL 8.4, saving or indexing products/product models fails with:

Could not convert database value "2026-03-20 12:08:24.000000" to Doctrine Type datetime_immutable. Expected format: Y-m-d H:i:s

Root Cause

MySQL 8.4 changed type coercion rules. When GREATEST() receives a mix of DATETIME and INTEGER arguments, the result is promoted to DATETIME(6), appending .000000 microseconds.
MySQL 8.0 returned plain DATETIME in the same scenario.

The affected queries use COALESCE(nullable_datetime_col, 0) where the integer 0 acts as a fallback for NULL:

-- Returns DATETIME(6) on MySQL 8.4:
GREATEST(product.updated, COALESCE(sub_product_model.updated, 0)) 

UTCDateTimeImmutableType then fails to parse the value because DateTimeImmutable::createFromFormat('Y-m-d H:i:s', '2026-03-20 12:08:24.000000') returns false due to trailing data.

Fix

Replace the integer 0 fallback with the row's own updated column, keeping all GREATEST() arguments as DATETIME:

-- Returns DATETIME on all MySQL versions:
GREATEST(product.updated, COALESCE(sub_product_model.updated, product.updated))

Semantically identical. When the parent is NULL, COALESCE returns product.updated, which can never win against itself in GREATEST().

Files Changed

• GetElasticsearchProductProjection.php:142
• GetElasticsearchProductModelProjection.php:101
• docker-compose.yml:80-81

How to Reproduce

1. Run Akeneo on MySQL 8.4.8
2. Edit and save any product
3. The Elasticsearch reindexing triggers the GREATEST/COALESCE query
4. UTCDateTimeImmutableType::convertToPHPValue() throws ConversionException

Related

There are additional hardening changes that could improve MySQL 8.4 compatibility as a safety net. UTCDateTimeImmutableType and UTCDateTimeType could be updated to fall back to Y-m-d H:i:s.u format when parsing fails, protecting against any other queries that might produce DATETIME(6) values on MySQL 8.4. This will be submitted as a separate PR #20625