mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
When property type is nullable, nullable attribute is not true #6788
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rixafy on GitHub (Jul 14, 2021).
Bug Report
Hello, I tried to use PHP type mapping and I also removed nullable property since it says it will be automatically determined when variable type is nullable as said in https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/basic-mapping.html#php-types-mapping
The problem occurred when I removed nullable column attributes, I tried to create migration with diff command (should be empty) but there is ~20 SQL statements for changing nullable columns to non-null, even when their type is nullable (for instance
?string), cache was clear when new migrations was generated.@rixafy commented on GitHub (Jul 14, 2021):
Ah, it's because someone didn't want it, but I don't understand why https://github.com/doctrine/orm/pull/8732
Why isn't variable nullability preferred? If someone want to have different nullability in DB and in code he can declare it with nullable argument.
It was already in 2.9, and it's not big BC break, since it was in 2.9 (removed in 2.9.2), and if someone has nullable variable but column is non-null, why would be variable nullable, what's the use-case for this?
It seems like it will only help detect potential problems as mentioned by @Slamdunk in https://github.com/doctrine/orm/pull/8732#issuecomment-852124660
Those people that had nullable types but didn't want them in DB will notice when they create next migration, and if it's somehow overlooked (worst case, developer should always check migration), it's not really a big issue, making column nullable.
@fridde commented on GitHub (Jul 26, 2021):
Just a comment:
Maybe not a big, but it is a BC break. Thus if we don't want to violate the pretty important rules of semantic versioning (and I really wouldn't want that) we'll have to wait for 3.0.
Check out this comment
@beberlei commented on GitHub (Aug 4, 2021):
Duplicate of previous discussions