Description
Feature Request
| Q | A |
|---|---|
| New Feature | yes |
| RFC | yes |
| BC Break | yes |
I would like to have nullable columns according to my PHP nullable properties, when column property is nullable, column should be also nullable, if there is no nullable attribute that says otherwise, I checked my entities in multiple big projects, and I have 1:1 nullable database values with nullable PHP properties.
#[Column]
private ?string $content = nullThis code should result in column being nullable in database, if there was declared #[Column(nullable: false)], column would not be nullable, but PHP variable can be, what is really bad practice, since entity can get into invalid state, and if it will be saved, application runs into an error. I thought about it, and I can't come up with one example where it's good to have nullable field in PHP, but not in database.
Previous discussions
This matter was discussed multiple times, once, this feature it was shipped into the 2.9.1 version, so some programmers (#8770, #8834) (me including) have removed nullable property from Column annotation, in version 2.9.2 it was reverted (#8732) and a BC break was introduced. I doubt there was many people that had different nullability in PHP.
Currently it's stated that it is not in 2.x because of backward compatibility (#8835), and main issue that caused rollback of the feature was this #8723 (and I think that only that one issue). And in that issue it was stated by @beberlei #8723 (comment) that you can look at it in ORM 3, what would be great, but then I asked about it recently, and got answer #9736 (comment)
No, nullability won't be deferred from property type declarations. This has been evaluated and discussed and we ultimately decided against it.
So, I'm curious based on what did you decide to not inherit nullability from PHP types?
Motivation
My vision is to have clean code, less bugs and less repeating declarations, ORM has been been going this way last couple of years.
For instance:
- There are mapped default PHP types to default doctrine types, in most cases we need only
#[Column]attribute. - Enums are supported and there is no need to declare anything (string, etc.), just enum type and
#[Column], not even enumType, since it's inherited from PHP type - Same with embedded, we only need to declare
#[Embedded] - We also don't need to declare
targetEntityin ManyToOne relationships, it's inherited from PHP type.
Also it enforces entity valid state, because if PHP value could be null and if there was non-null column in database, after flushing the entity there will be a SQL error. So there is that.
And if someone want nullable type to be non-nullable in database, they can simply declare nullable: false in #[Column] attribute.
Another thing is, that happened to me a few times, that I totally forgot to declare nullable columns in annotations additionally, and I discovered it after I wanted to save entity, that PHP values could be nullable, but database columns could not.
Here is an example of that mentioned code where I needed to add additional nullable attribute and how bad it looks
And here is same code without that attribute nullability declarations