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
PHP 7.4 Typed Ids musts be nullable to remove an entity #7999
Comments
Checking for allows null seems like the sensible approach. |
Fix should be in doctrine/persistence |
@beberlei isn't this fixed by https://github.com/doctrine/reflection/releases/tag/1.2.0? |
@enumag I still have this bug, I use doctrine/reflection 1.2.1. The bug appears as soon as I added a ManyToMany relation between the same entity. |
@Alexandre-T What is the version of your doctrine/persistence? If it is 1.3.6+, can you post the exact error message and relevant part of stack trace? It seems your case is elsewhere than what was fixed. |
@enumag doctrine/persistence 1.3.7
And here is the simplified code of my User entity: //...
class User implements //....
{
//...
/**
* @ORM\ManyToMany(targetEntity="App\Entity\Station", inversedBy="users")
*
* @var Collection|Station[]
*
* @Groups({"owner:user:read", "animator:user:read"})
*/
private Collection $stations;
/**
* Referent of this user.
*
* @ORM\ManyToOne(targetEntity="App\Entity\User")
*/
private ?User $referent = null;
/**
* User constructor.
*/
public function __construct()
{
$this->stations = new ArrayCollection();
}
} |
@Alexandre-T Ah, actually that's a different issue. See doctrine/common#886. |
Hi, there are any news about this issue ? I have the same problem when I want to delete an entity....
The version of packages :
EDITIt works in private property id. Because the PR https://github.com/doctrine/reflection/pull/35/files is only on private properties. Thanks to add this code on public properties ? |
Honestly, after going through things with this for a while now, we've decided that allowing null for an Firstly, it allows for us to tell if the entity has been persisted. Relying on the EntityManager is not sufficient. And, in a state where an object has been created and not persisted, that value being null, and accessible, is the most sane state/type IMO. If there was a more direct way to check if a value has been initialized, maybe that'd be better, but I'm not aware of a clean way of doing that right now (reflection isn't an option IMO). |
I've added a fix for public properties here: doctrine/persistence#103 Just need a review :) |
I also encountered this issue and read the previous posts. I strongly disagree with @oojacoboo opinion saying the best solution is to make them nullable for the following reasons (I will refer to symfony 5 projects because letely that's what I've been working on, but I'm sure is rather general):
Making ids (or any other property for that matter but ids are affected mostly) nullable will pollute my code with thousands of useless checks making it less readable and less maintainable. Also a little bit slower but that is negligible in 99.99% of real life cases so that is not my main issue, but the useless code is.
Fix suggestion: |
@elzozo13 I’d like to clarify that we almost always assume an auto generated “id” exists. If you’re frequently dealing with objects where that may not be the case, I’d agree and not advise you to make your id nullable |
Related to doctrine/orm#7999 I'm using typed properties with a default value that is not null. Example: ```php class Entity { /** * @Orm\Column(name="id", type="integer") * @Orm\Id * @Orm\GeneratedValue(strategy="AUTO") */ private int $id = 0; } This works great. When inserting a new entity in the database, the auto incremented id is updated properly. It means that entities that are not persisted will have a `0` as id and the rest will have another integer value. But upon deleting an entity this becomes a problem. The ORM tries to set the `id` property value to `null` and that causes a TypeError: ``` TypeError: Typed property Entity::$id must be int, null used vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1246 vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:441 vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:376 ``` With this change applied, the default value of the `id` property `0` is used again. Solving the problem.
Related to doctrine/orm#7999 I'm using typed properties with a default value that is not null. Example: ```php class Entity { /** * @Orm\Column(name="id", type="integer") * @Orm\Id * @Orm\GeneratedValue(strategy="AUTO") */ private int $id = 0; public function getId() : int { return $this->id; } } This works great. When inserting a new entity in the database, the auto incremented id is updated properly. It means that entities that are not persisted will have a `0` as id and the rest will have another non-zero integer value. But upon deleting an entity this becomes a problem. The ORM tries to set the `id` property value to `null` and that causes a TypeError: ``` TypeError: Typed property Entity::$id must be int, null used vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1246 vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:441 vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:376 ``` With this change applied, the default value of the `id` property `0` is used again. Solving the problem.
Related to doctrine/orm#7999 I'm using typed properties with a default value that is not null. Example: ```php class Entity { /** * @Orm\Column(name="id", type="integer") * @Orm\Id * @Orm\GeneratedValue(strategy="AUTO") */ private int $id = 0; public function getId() : int { return $this->id; } } ``` This works great. When inserting a new entity in the database, the auto incremented id is updated properly. It means that entities that are not persisted will have a `0` as id and the rest will have another non-zero integer value. But upon deleting an entity this becomes a problem. The ORM tries to set the `id` property value to `null` and that causes a TypeError: ``` TypeError: Typed property Entity::$id must be int, null used vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1246 vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:441 vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:376 ``` With this change applied, the default value of the `id` property `0` is used again. Solving the problem.
In my project I was using auto incremented integers and decided to type them like this: class Entity {
/**
* @ORM\Column(name="id", type="integer")
* @ORM\Id
* @ORM\GeneratedValue(strategy="AUTO")
*/
private int $id = 0;
public function getId() : int
{
return $this->id;
}
} It works great until I try to remove the entity. Giving me:
I created a PR in doctrine/persistence to use the default property value when setting null. I'm wondering: Does this make any sense? Is this crazy? Am I overlooking something, or is this the solution? 😊 |
@ruudk That's an undesirable hack. I'd rather have it be null than zero/int. I'm not really sure what you gain by doing this. |
I have experienced the same issue on php 8. |
IIUC there's a fix proposed: doctrine/persistence#103 but was hold as a BC break (wrong branch), then 2.0 was released without it 😞 |
I totally forgot that MR, and github wasn't sending me any updates on it - I'll try to fix the issues as soon as possible :) |
[FIXED] For those for whom these instructions do not work. The same issue here.
My composer.json:
UnitOfWork->Line 1107:
Following what @leongersen said " A potential solution would be to check if the reflField allows null (->getType()->allowsNull())." He was right. UnitOfWork->Line 1107:
FIXED 4me at least. I can finally deleting. |
avoiding null checks is one gain. |
Bug Report
Summary
This is closely related to #7940, which reports the UnitOfWork accessing properties before initialization. This was resolved in
doctrine/persistence
1.3.6.With that update, Ids must still be nullable to be able to remove the entity, as the
UnitOfWork
will be setting the id value back to null in\Doctrine\ORM\UnitOfWork::executeDeletions
:Adding a non-nullable type to a property and trying to remove it results in the following error:
I'm not sure this necessarily qualifies as a bug in
orm
, but I'm not sure what else to call it. A potential solution would be to check if thereflField
allows null (->getType()->allowsNull()
).The text was updated successfully, but these errors were encountered: