-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: enumType
: Allow hydrating non-existing backed value as NULL (i.e. use ::tryFrom($value)
instead of ::try($value)
)
#9433
Comments
As long as the feature is opt-in and does not generate too many edge cases, I'd be fine merging it. Do you want to provide a PR? |
That's the answer I was most afraid of ;-) I will give it a try - some questions in advance:
|
I took your idea and extended it to allow setting any default value in case DB value cannot be cast to corresponding |
I am unsure about this, because why not handle all other kind of invalid data as null then? We throw exceptions when db has invalid dsta for a datetime for example. Databases and ORMs enforce structure on data and migrations before deployment are essential. Making an exception for enums feels wrong |
So So i cant use |
It does. |
To clarify: You can use |
ahh my fail i found the problem. thanks for clarification. |
Feature Request
Summary
TL;DR:
I'm suggesting an option for
enumType
so that when fetching a value from the database which is not present in the enum, the property is hydrated asnull
, instead of throwing aValueError
.@derrabus: This is my answer to #9021 (comment), after gaining some real-world experience and some more thinking.
Real example: I'm having a
Product
entity which has an enum columntype
, holding some less-important information (just for internal use). Now I had to add a new case toTypeEnum
. I did this only on the internal machine (where the admin backend is running), and didn't deploy it. Result: The product is not shown in production, even though - and this is the crucial part of the story - thetype
isn't even displayed there!Lessons learnt: Whenever you need to reorganize the enum values, you need to have (1) the access rights, (2) the knowledge, and (3) the time to run the code deployment and the database migration simultaneously.
What I'd like to point out is that there are unimportant database columns (for statistics, internal use, whatever). So I think developers should have the choice to define enum columns as either "crucial" (i.e. exception when inconsistent) or "unimportant" (i.e.
NULL
when inconsistent).I think it's happening at this line: https://github.com/doctrine/orm/blob/2.11.x/lib/Doctrine/ORM/Mapping/ReflectionEnumProperty.php#L71 So my suggestion would be to allow switching this to
::tryFrom()
.The text was updated successfully, but these errors were encountered: