fix(doctrine): avoid deprecated ArrayAccess on FieldMapping in DoctrineORMListener#506
Conversation
- Updated field mapping logic to support both legacy array mapping and the new FieldMapping object introduced in Doctrine ORM 3.x. - Ensured backward compatibility with existing implementations while preparing for future ORM 4.0 changes.
|
Thanks for maintaining LexikTranslationBundle — it would be great if one of the maintainers could review this PR when you have a moment. Happy to adjust anything based on your feedback. |
|
Hi maintainers, Just following up on this PR. It addresses the Doctrine ORM 3.x deprecation caused by using ArrayAccess on The change keeps the existing behavior intact while making the metadata access compatible with the newer Doctrine mapping API, and it also closes #491. Would it be possible to review or merge this when you have a chance? Happy to make any adjustments if needed. Thanks again for maintaining this bundle. |
| $fieldMapping['length'] = 191; | ||
| $metadata->fieldMappings[$name] = $fieldMapping; | ||
| } | ||
| } else { |
There was a problem hiding this comment.
If you use continue after line 32, you can remove the else. What do you think? And where does the hardcoded 191 come from. I know that is not your change, but just out of curiosity... why?
There was a problem hiding this comment.
Thanks for the review!
Re: continue vs else — Good point, I'll refactor the loop to use continue after the array branch so we can drop the else. Cleaner that way.
Re: the hardcoded 191 — That value predates this PR; it was introduced in #238 (2017). It's the MySQL/InnoDB limit for indexable VARCHAR columns under utf8mb4: with the classic 767-byte index key limit and up to 4 bytes per character, the safe maximum is 191 (767 ÷ 4). Without capping string field lengths, schema creation can fail with "Specified key was too long" when the connection charset is utf8mb4. This listener adjusts the mapping at metadata load time for TranslationBundle entities only.
…atibility - Adjusted the handling of field mappings to ensure proper support for the FieldMapping object in Doctrine ORM 3.x. - Removed deprecated ArrayAccess usage to prepare for future ORM 4.0 changes, enhancing code maintainability.
2 participants
Fix Doctrine ORM 3 FieldMapping ArrayAccess deprecation
This PR fixes a Doctrine ORM 3.x deprecation triggered when accessing
FieldMappingmetadata using array syntax.Doctrine ORM deprecated
ArrayAccessonDoctrine\ORM\Mapping\FieldMappingindoctrine/orm#11211, and this behavior is expected to be removed in ORM 4.0.As a result, code like this:
can trigger the following deprecation notice:
Context
The deprecation is currently triggered in
DoctrineORMListener::loadClassMetadata, where the bundle checks the mapped field type before adjusting the length of string fields for MySQL connections using theutf8mb4charset.The existing behavior is preserved:
stringare considered;191when the connection charset isutf8mb4.What changed
This PR replaces direct array access to the Doctrine field mapping with a small helper method that resolves the field type safely from either:
Doctrine\ORM\Mapping\FieldMappingobject, using its publictypeproperty;typekey.This keeps the code compatible with Doctrine ORM 3.x while remaining tolerant of array-based metadata mappings.
Why
This removes the Doctrine ORM 3.x deprecation notice and prepares this part of the bundle for Doctrine ORM 4 compatibility, without changing the existing behavior of the metadata adjustment logic.
Tests
Not run locally. The change is limited to metadata mapping access and preserves the existing logic.
Fixes #491.