DDC-3730: Embeddable hydrates to object instead of null

[doctrinebot]

Jira issue originally created by user pcnc:

Good afternoon,

When hydrating an Embeddable with nullable attributes the result is an instance of the Embeddable class , this is obviously correct and expected behavior.

If all the attributes are null the hydrator will still return an instance of the class with all of its properties null , even if I persist and flush my Entity with the Embeddable being set as null .

For clarification :

class MyEntity
{
    protected $myEmbeddable;

    public function setMyEmbeddable(MyEmbeddable $myEmbeddable = null)
    {
        $this->myEmbeddable = $myEmbeddable;
    }
    [...]
}

$newEntity = new MyEntity();
$newEntity->setMyEmbeddable(null);

$em->persist($newEntity);
$em->flsuh($newEntity);

Calling $newEntity->getMyEmbeddable() will return an instance of the MyEmbeddable object with all of it's attributes set to null .

I expected $newEntity->getMyEmbeddable() to be NULL .

Can someone clarify is this is expected behaviour ? In case it is , how can I achieve what I'm looking for ?

Best regards

[doctrinebot]

Comment created by eugene-d:

See #1275

[boekkooi]

This is actually really confusing definitely when you combine it with the docs

[afoeder]

I must say I find this rather a bug than an improvement... agree with @boekkooi regarding the docs...

[Ocramius]

Can anyone confirm if this is a dupe of #4670 and #4568?

[afoeder]

well this is #4568; and #4670 is rather a duplicate of #1275, both actually "features" or "improvements".

This here however is a Bug because embeddables whose all properties are nullable and being null hydrate to an empty object when being stored as null. This is misleading (saving != retrieving) and not according to the docs.

[Ocramius]

@afoeder the order of the tickets is scrambled due to the fact that they were imported from Jira in December, heh

[Harrisonbro]

Hi @Ocramius

Has there been any further discussion on this topic? We've just hit into the same problem as described here on our first Doctrine project.

Let me know if there's anything we can do to help — provide usage examples, code samples, discussions, etc.

[Ocramius]

@Harrisonbro as it currently stands, doctrine will not support nullable embeddables. That functionality may be implemented later, by implementing embeddables as hidden one-to-one records.

[Harrisonbro]

OK. Is there any way for us to implement this on a case-by-case basis (eg. by hooking into the hydration process of an embeddable somehow) so we can manually check whether specific embeddables have enough data in the database to be considered 'valid' and therefore hydratable? Obviously we're not keen to allow value objects to be instantiated in an invalid state and then check an isValid method.