Fix BIGINT validation#11414
Conversation
6eda1f9 to
1b6d35e
Compare
1b6d35e to
f756989
Compare
|
This will probably make us revert most of #11399 by @ThomasLandauer when merging up. |
* 2.19.x: Fix BIGINT validation (doctrine#11414) Fix templated phpdoc return type (doctrine#11407) [Documentation] Merging "Query Result Formats" with "Hydration Modes" Fix psalm errors: remove override of template type Update dql-doctrine-query-language.rst Adding `NonUniqueResultException` [Documentation] Query Result Formats
* 2.19.x: Fix BIGINT validation (doctrine#11414) Fix templated phpdoc return type (doctrine#11407) [Documentation] Merging "Query Result Formats" with "Hydration Modes" Fix psalm errors: remove override of template type Update dql-doctrine-query-language.rst Adding `NonUniqueResultException` [Documentation] Query Result Formats
* 2.19.x: Fix BIGINT validation (doctrine#11414) Fix templated phpdoc return type (doctrine#11407) [Documentation] Merging "Query Result Formats" with "Hydration Modes" Fix psalm errors: remove override of template type Update dql-doctrine-query-language.rst Adding `NonUniqueResultException` [Documentation] Query Result Formats
* 2.19.x: Fix BIGINT validation (doctrine#11414) Fix templated phpdoc return type (doctrine#11407) [Documentation] Merging "Query Result Formats" with "Hydration Modes" Fix psalm errors: remove override of template type Update dql-doctrine-query-language.rst Adding `NonUniqueResultException` [Documentation] Query Result Formats
* 2.19.x: Fix BIGINT validation (#11414) Fix templated phpdoc return type (#11407) [Documentation] Merging "Query Result Formats" with "Hydration Modes" Fix psalm errors: remove override of template type Update dql-doctrine-query-language.rst Adding `NonUniqueResultException` [Documentation] Query Result Formats
* 3.1.x: Revert "Merge pull request #11399 from ThomasLandauer/issue-11377" (#11415) Fix BIGINT validation (#11414) docs: update PHP version in doc Fix fromMappingArray definition Fix templated phpdoc return type (#11407) [Documentation] Merging "Query Result Formats" with "Hydration Modes" SchemaValidator: Changing mapping of BIGINT to string|int Fix psalm errors: remove override of template type Update dql-doctrine-query-language.rst Adding `NonUniqueResultException` [Documentation] Query Result Formats
* 3.2.x: Revert "Merge pull request #11399 from ThomasLandauer/issue-11377" (#11415) Fix BIGINT validation (#11414) docs: update PHP version in doc Fix fromMappingArray definition Fix templated phpdoc return type (#11407) [Documentation] Merging "Query Result Formats" with "Hydration Modes" SchemaValidator: Changing mapping of BIGINT to string|int Fix psalm errors: remove override of template type Update dql-doctrine-query-language.rst Adding `NonUniqueResultException` [Documentation] Query Result Formats
|
@derrabus @greg0ire I don't think this is valid - at least not for orm 2.x and dbal 3.x. Relying on PHP to cast the value to an This is because Lines 787 to 790 in b725908 ===. And that value will still be a string, so '1' === 1 fails and the property will be added to the changeset even if the entity has not actually changed.
We were bitten by this in production a while ago and realised that in fact you can only safely use |
Are you sure?
|
|
@greg0ire with DBAL 3.x it will be, yes - I tested locally. With DBAL 4.x I suppose it will vary - in theory if you had code running on different platforms then sometimes the data in the UnitOfWork->originalEntityData will be a string and sometimes an int (depending on actual value, it won't be consistent to the platform). So you might sometimes get a false-dirty entity if you have typed the entity to always take |
|
I think you're correct. On |
|
I'll look into it. |
|
My main problem is this:
I don't want to projects to do big migrations to string properties just to revert back to integers once DBAL 4 is installed. That's why I'd rather not emit an error in this special case. But you are right, with |
|
The safest thing might be to update UnitOfWork to cope with this case and e.g. cast both original & current value back to I think that would still detect genuine changes, but avoid any risk of accidental changesets across both DBAL 3&4 and all platforms / possible values? Similar to how UnitOfWork already has a workaround to cast enums in the entity properties back to strings before comparing to the DBAL value Off the top of my head I don't think that would break any existing behaviour if it was possible to apply it only to |
Fixes #11377.
Our schema validation currently fails if we map a
BIGINTcolumn to a property with anintPHP type. While this is technically correct because DBAL 3 hydratesBIGINTvalues as strings, the error is also unnecessarily strict:The ORM will cast strings returned by DBAL back to
int, if that's the property type. The value range ofBIGINTand PHP's int (on 64bit machines) is the same. StoringBIGINTvalues as string is only necessary if we run on 32bit PHP or we deal withBIGINT UNSIGNEDon MySQL/MariaDB. Both are edge cases a project may validly choose to ignore.Emitting this error encourages downstream projects to change their property types of
BIGINTcolumns frominttostringwhich is unfortunate given that DBAL 4 moved towards returning integers if possible.