Revert "SchemaValidator: Changing mapping of BIGINT to string|int"#11415
Conversation
|
So I did it in 3.1 and you did the ~same in 2.19 and now propagate/cascade/inherit it to 3.1? And this is called an upmerge? But what are "downstream projects"? So the bottom line stays the same: This is the way to go for the future?: #[Column(type: Types::BIGINT)]
private string|int $bigint; |
Yes, see #11416.
Your application.
That would be valid, although I personally prefer this version for my projects: #[Column(type: Types::BIGINT)]
private int $bigint; |
* 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
|
Upstream projects from the ORM's perspective would be DBAL, Persistence, Symfony VarExporter, the PHP runtime, …
✌🏻 |
I'm reverting #11399 in favor of an upmerge of #11414 which gives us a more consistent developer experience across DBAL and ORM releases.
cc @ThomasLandauer