Non-nullable typed property for Embeddable should be ignored when hydrating #6397

New Issue

admin · 2026-01-22T15:32:28+01:00

admin commented

2026-01-22 15:32:28 +01:00

Originally created by @sneakyvv on GitHub (Feb 6, 2020).

Bug Report

Q	A
BC Break	no
Version	2.7.0

Summary

Required typed properties of nullable embeddables can not be hydrated in PHP 7.4.

Current behavior

Take this example:

/**
 * @ORM\Entity()
 */
class Foo
{    
    /**
     * @ORM\Embedded(class="App\Domain\Model\Bar")
     */
    private ?Bar $bar = null;
}

and the Embeddable

/**
 * @ORM\Embeddable()
 */
class Bar
{
    /**
     * @ORM\Column(type="datetime_immutable", nullable=true)
     */
    private \DateTimeImmutable $startDate;
}

So, the $bar property on Foo can be null, but when it is provided it should have a $startDate. However, since it's part of the Embeddable, it could be null in the database for the table foo.
But, when it's hydrated it should not set that null value, otherwise you get this error:

Typed property App\Domain\Model\Bar::$startDate must be an instance of DateTimeImmutable, null used - #0 ..lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php(99): ReflectionProperty->setValue(Object(App\Domain\Model\Bar), NULL)

How to reproduce

See example above, create an instance of Foo, save it and load/hydrate it again.

Expected behavior

IMO, a null value, for non-nullable typed properties should be ignored in Embeddables.

PS: Kinda related to #4568, because when all properties of the Embeddable are null, the parent property should also be null (which I fix now post-hydrating), but that occurs even later obviously, after all properties of the Embeddable are set.

Originally created by @sneakyvv on GitHub (Feb 6, 2020). ### Bug Report | Q | A |------------ | ------ | BC Break | no | Version | 2.7.0 #### Summary Required typed properties of nullable embeddables can not be hydrated in PHP 7.4. #### Current behavior Take this example: ``` /** * @ORM\Entity() */ class Foo { /** * @ORM\Embedded(class="App\Domain\Model\Bar") */ private ?Bar $bar = null; } ``` and the Embeddable ``` /** * @ORM\Embeddable() */ class Bar { /** * @ORM\Column(type="datetime_immutable", nullable=true) */ private \DateTimeImmutable $startDate; } ``` So, the `$bar` property on `Foo` can be null, but when it is provided it should have a `$startDate`. However, since it's part of the Embeddable, it could be `null` in the database for the table `foo`. But, when it's hydrated it should not set that null value, otherwise you get this error: ``` Typed property App\Domain\Model\Bar::$startDate must be an instance of DateTimeImmutable, null used - #0 ..lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php(99): ReflectionProperty->setValue(Object(App\Domain\Model\Bar), NULL) ``` #### How to reproduce See example above, create an instance of Foo, save it and load/hydrate it again. #### Expected behavior IMO, a null value, for non-nullable typed properties should be ignored in Embeddables. PS: Kinda related to #4568, because when all properties of the Embeddable are null, the parent property should also be null (which I fix now post-hydrating), but that occurs even later obviously, after all properties of the Embeddable are set.

admin commented

2026-01-22 15:32:29 +01:00

@beberlei commented on GitHub (Feb 12, 2020):

@sneakyvv which version of doctrine/persistence and doctrine/reflection are you on? The latest ones contain fixes for typed propreties, I hoped they work on embeddables as well.

@beberlei commented on GitHub (Feb 12, 2020): @sneakyvv which version of doctrine/persistence and doctrine/reflection are you on? The latest ones contain fixes for typed propreties, I hoped they work on embeddables as well.

admin commented

2026-01-22 15:32:29 +01:00

@sneakyvv commented on GitHub (Feb 12, 2020):

@beberlei, I saw the ticket handling that, and upgrade my packages, but the mentioned bug still happened.

My current versions are:
doctrine/persistence: 1.3.6
doctrine/reflection: 1.1.0

@sneakyvv commented on GitHub (Feb 12, 2020): @beberlei, I saw the ticket handling that, and upgrade my packages, but the mentioned bug still happened. My current versions are: doctrine/persistence: 1.3.6 doctrine/reflection: 1.1.0

admin commented

2026-01-22 15:32:29 +01:00

@sneakyvv commented on GitHub (Feb 12, 2020):

@beberlei I've made the test work (or be skipped) for older PHP versions.

Travis is now passing, since I've conditionally included a file containing the php7.4-style classes.
Is there a better, more elegant way to include such conditional code in the test file itself? The purpose is to avoid syntax errors for older versions.

@sneakyvv commented on GitHub (Feb 12, 2020): @beberlei I've made the test work (or be skipped) for older PHP versions. Travis is now passing, since I've conditionally included a file containing the php7.4-style classes. Is there a better, more elegant way to include such conditional code in the test file itself? The purpose is to avoid syntax errors for older versions.

admin referenced this issue

2026-01-22 16:06:01 +01:00

[PR #6397] This should fix Criteria startsWith and endsWith #9968

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6397