Typed property must not be accessed before initialization #6360

@oojacoboo commented on GitHub (Dec 5, 2019):

Yea, had a good discussion on Slack about this. I suspect that many other people will run into this issue as PHP 7.4 begins to be adopted more and people start typing their properties.

We'll just use protected ?int $id = null. This has a fringe benefit in allowing you to identify if the Entity has been persisted and makes sense for a default value with auto-increment on most RDBMSes.

@oojacoboo commented on GitHub (Dec 5, 2019): Yea, had a good discussion on Slack about this. I suspect that many other people will run into this issue as PHP 7.4 begins to be adopted more and people start typing their properties. We'll just use `protected ?int $id = null`. This has a fringe benefit in allowing you to identify if the Entity has been persisted and makes sense for a default value with auto-increment on most RDBMSes.

admin commented

@pfazzi commented on GitHub (Dec 6, 2019):

I have the same issue, ATM i'm adopting the private ?int $id = null; strategy.

@pfazzi commented on GitHub (Dec 6, 2019): I have the same issue, ATM i'm adopting the `private ?int $id = null;` strategy.

admin commented

@kyrrr commented on GitHub (Jan 7, 2020):

Would be nice to have a different solution than setting nullables everywhere.

@kyrrr commented on GitHub (Jan 7, 2020): Would be nice to have a different solution than setting nullables everywhere.

admin commented

https://github.com/doctrine/orm/pull/7857

@oojacoboo commented on GitHub (Jan 7, 2020):

@kyrrr it's totally fixable. There is an open pull request related to this, but it seems more needs to be done on it and there hasn't been much activity recently.

@oojacoboo commented on GitHub (Jan 7, 2020): @kyrrr it's totally fixable. There is an open pull request related to this, but it seems more needs to be done on it and there hasn't been much activity recently. https://github.com/doctrine/orm/pull/7857

admin commented

2026-01-22 15:31:47 +01:00

@beberlei commented on GitHub (Jan 17, 2020):

Updating doctrine/persistence to 1.3.6 will fix this issue.

@beberlei commented on GitHub (Jan 17, 2020): Updating doctrine/persistence to 1.3.6 will fix this issue.

admin commented

@leongersen commented on GitHub (Jan 22, 2020):

Unfortunately, even with the updates to doctrine/persistence, ids must 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:

// Entity with this $oid after deletion treated as NEW, even if the $oid
// is obtained by a new entity because the old one went out of scope.
//$this->entityStates[$oid] = self::STATE_NEW;
if ( ! $class->isIdentifierNatural()) {
	$class->reflFields[$class->identifier[0]]->setValue($entity, null);
}

I've filed this issue: #7999

@leongersen commented on GitHub (Jan 22, 2020): Unfortunately, even with the updates to `doctrine/persistence`, ids must 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`: ```php // Entity with this $oid after deletion treated as NEW, even if the $oid // is obtained by a new entity because the old one went out of scope. //$this->entityStates[$oid] = self::STATE_NEW; if ( ! $class->isIdentifierNatural()) { $class->reflFields[$class->identifier[0]]->setValue($entity, null); } ``` I've filed this issue: #7999

admin commented

2026-01-22 15:31:47 +01:00

@artyom-wcd commented on GitHub (Mar 6, 2020):

using this: "name": "doctrine/persistence", "version": "1.3.6",
but the problem (as described before) is still there when trying to flush

@artyom-wcd commented on GitHub (Mar 6, 2020): using this: "name": "doctrine/persistence", "version": "1.3.6", but the problem (as described before) is still there when trying to flush

admin commented

2026-01-22 15:31:47 +01:00

@oojacoboo commented on GitHub (Mar 6, 2020):

Can the property just be unset or, by using reflection, check if nullable and optionally set as null?

Deletion is an interesting scenario. Technically, unless using soft-delete, that object shouldn't really exist anymore, and certainly not the ID. I can see how it'd be useful to use an object after deletion though.

@oojacoboo commented on GitHub (Mar 6, 2020): Can the property just be `unset` or, by using reflection, check if nullable and optionally set as null? Deletion is an interesting scenario. Technically, unless using soft-delete, that object shouldn't really exist anymore, and certainly not the ID. I can see how it'd be useful to use an object after deletion though.

admin commented

@yapro commented on GitHub (Mar 19, 2020):

My error:

"Typed property Proxies\\__CG__\\App\\Entity\\Organization::$ must not be accessed before initialization (in __sleep)"

My solution - add next method to the class:

public function __sleep()
{
    return [];
}

@yapro commented on GitHub (Mar 19, 2020): My error: ``` "Typed property Proxies\\__CG__\\App\\Entity\\Organization::$ must not be accessed before initialization (in __sleep)" ``` My solution - add next method to the class: public function __sleep() { return []; }

admin commented

@VaN-dev commented on GitHub (Jun 23, 2020):

Updating doctrine/persistence to 1.3.6 will fix this issue.

it doesn't

@VaN-dev commented on GitHub (Jun 23, 2020): > Updating doctrine/persistence to 1.3.6 will fix this issue. it doesn't

admin commented

@Amunak commented on GitHub (Aug 18, 2020):

What about properties where you can't set the default value, like in associations that use collection? Object cannot be a default value, and nullable makes no sense here.

This example:

class Entity {
    	/**
	 * @ORM\OneToMany(targetEntity="Other")
	 * @var Collection|Other[]
	 */
	protected $friends;
	public function __construct() {
		$this->friends = new ArrayCollection();
	}
}

used to be the proper way to initialize collections, but now if you add PHP7.4 property type hints (protected Collection $friends;) it no longer works, as Doctrine accesses the property through reflection but doesn't run the constructor and then you get the Fatal Error.

And that's not the only example, what about custom Doctrine types that use some object to hold the value?

@Amunak commented on GitHub (Aug 18, 2020): What about properties where you can't set the default value, like in associations that use collection? Object cannot be a default value, and nullable makes no sense here. This example: ```php class Entity { /** * @ORM\OneToMany(targetEntity="Other") * @var Collection|Other[] */ protected $friends; public function __construct() { $this->friends = new ArrayCollection(); } } ``` used to be the proper way to initialize collections, but now if you add PHP7.4 property type hints (`protected Collection $friends;`) it no longer works, as Doctrine accesses the property through reflection but doesn't run the constructor and then you get the Fatal Error. And that's not the only example, what about custom Doctrine types that use some object to hold the value?

admin commented

@Ocramius commented on GitHub (Aug 18, 2020):

but now if you add PHP7.4 property type hints (protected Collection $friends;) it no longer works, as Doctrine accesses the property through reflection but doesn't run the constructor and then you get the Fatal Error.

Proxy initialization does set collections?

What doesn't work (and also didn't work in the past) in the 2.x series is "friend objects", but otherwise proxy initialization does populate their associations.

This is the broken behavior (also pre-php-7.4):

class Thing
{
    private $id;
    private $lazyField;
    function equals(self $other) {
        return $other->lazyField->equals($this->lazyField); // call to `equals` on `null` happening here
    }
}

@Ocramius commented on GitHub (Aug 18, 2020): > but now if you add PHP7.4 property type hints (`protected Collection $friends;`) it no longer works, as Doctrine accesses the property through reflection but doesn't run the constructor and then you get the Fatal Error. Proxy initialization does set collections? What doesn't work (and also didn't work in the past) in the 2.x series is "friend objects", but otherwise proxy initialization does populate their associations. This is the broken behavior (also pre-php-7.4): ```php class Thing { private $id; private $lazyField; function equals(self $other) { return $other->lazyField->equals($this->lazyField); // call to `equals` on `null` happening here } } ```

admin commented

@oojacoboo commented on GitHub (Aug 18, 2020):

@Ocramius That's partially right. But, you don't need the call to equals there. You only need the call on lazyField, which is the issue. It's of particular concern for auto incremented IDs. You make it sound like this has always been an issue and it's not an important one.

@oojacoboo commented on GitHub (Aug 18, 2020): @Ocramius That's partially right. But, you don't need the call to `equals` there. You only need the call on `lazyField`, which is the issue. It's of particular concern for auto incremented IDs. You make it sound like this has always been an issue and it's not an important one.

admin commented

@Amunak commented on GitHub (Aug 18, 2020):

Proxy initialization does set collections?

Interesting, for some reason I have this issue only in our Jenkins test build but can't replicate it locally. I'll investigate further.

@Amunak commented on GitHub (Aug 18, 2020): > Proxy initialization does set collections? Interesting, for some reason I have this issue only in our Jenkins test build but can't replicate it locally. I'll investigate further.

admin commented

@Ocramius commented on GitHub (Aug 18, 2020):

@Ocramius That's partially right. But, you don't need the call to equals there. You only need the call on lazyField, which is the issue. It's of particular concern for auto incremented IDs. You make it sound like this has always been an issue and it's not an important one.

@oojacoboo yes, I made the example to show that the method call will lead to a crash: much harder to notice if I used === there :)

@Ocramius commented on GitHub (Aug 18, 2020): > @Ocramius That's partially right. But, you don't need the call to `equals` there. You only need the call on `lazyField`, which is the issue. It's of particular concern for auto incremented IDs. You make it sound like this has always been an issue and it's not an important one. @oojacoboo yes, I made the example to show that the method call will lead to a crash: much harder to notice if I used `===` there :)

admin commented

@Amunak commented on GitHub (Aug 19, 2020):

Alright, investigation concluded; when clearing cache on Jenkins no APP_ENV was defined so it cleared the default, but we needed other envs cleared. This lead to old metadata being used from cache and in those Doctrine didn't even know about some of the fields, skipping the initialization.

Sorry, my mistake.

@Amunak commented on GitHub (Aug 19, 2020): Alright, investigation concluded; when clearing cache on Jenkins no APP_ENV was defined so it cleared the default, but we needed other envs cleared. This lead to old metadata being used from cache and in those Doctrine didn't even know about some of the fields, skipping the initialization. Sorry, my mistake.

admin commented