orm: Incorrect Mapping of BackedEnum
Bug Report
doctrine/orm/lib/Doctrine/ORM/Mapping/ReflectionEnumProperty.php is not able to inizialize enum from its value
| Q | A |
|---|---|
| Doctrine\Dbal Version | 3.4.5 |
| symfony* | 6.1.3 |
| api-platform/core | 2.7.0 |
Summary
in version 3.4.4 BackedEnum are mapped correctly
Current behaviour
"App\\Enum\\VatClassEnum::from(): Argument doctrine/dbal#1 ($value) must be of type string, App\\Enum\\VatClassEnum given"
basilicaly the value of $value should be a string not a BackeEnum
How to reproduce
backed enum
enum VatClassEnum : string { case I = 'I'; case C = 'C'; }
create an entity with the following field
#[ORM\Column(length : 4, nullable : true, enumType : VatClassEnum::class)] private ?VatClassEnum $vatClass = null;
Expected behaviour
correct hydratation of entity
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 16
- Comments: 16 (7 by maintainers)
@devtronic Nothing stops you from simply adding
"conflict": { "doctrine/orm": "2.13.2" }to yourcomposer.jsonwhile this is sorted out.@devtronic I gave an estimate, don’t tell me you’re going to treat it as a deadline? Who are you, a project manager?
Very, very soon: https://github.com/doctrine/orm/releases/tag/2.13.3
Hello, I have the same issue. It is already fixed in
2.13.x-devwith https://github.com/doctrine/orm/pull/10058 I’m just waiting for the next release 😄This issue is introduced with 2.13.2, 2.13.1 works fine.
Will consider it next time, thanks 👍
Only if someone already changed the definition to
2.13.2or^2.13.2, and it would give a clear error that there is no longer a release matching the constraints. If the constraint still matches2.13.1Composer would just happily downgrade on the next update. Yanking is a very valid scenario in the case of accidentally releasing breaking bugs and fully supported by both Composer and Packagist.https://github.com/composer/packagist/issues/152
edit: and thanks for the new release 😃
This also fundamentally broke several of my production environments overnight today. While the conflict workaround is fine of course I do think the severe impact of this bug warrants actually yanking the 2.13.2 release - I upgraded 3 days ago while the cause was determined 7 days ago, I wouldn’t have been affected had it been yanked.
Thank you @greg0ire and everyone involved for your effort and the quick fix!
I can confirm this 😄