Embedded entities unsupported by hydrator

[Bilge]

The hydrator (DoctrineObject) does not support the new embeddables feature at this time.

[gianarb]

Can you paste your test?
Thanks 👍

[Bilge]

What? What test?

[gianarb]

How have you tried embeddable entity into DoctrineObject?

[danizord]

Related to #449, ping @fabiocarneiro

[Bilge]

Why would I try something that is unsupported?

[Bilge]

This is still a serious issue, even in Mongo.

[TomHAnderson]

Since #449 has been resolved is this still an issue?

[bitwombat]

Since #449 has been resolved is this still an issue?

I can't quite grok #449 and others referenced, but I think it still is an issue.

When using HydrateByValue with embeddables, I'm seeing the aggregate's setMyEmbeddable method get called, but with an array of values.

Bottom line is I get this exception:

ReflectionProperty::getValue() expects parameter 1 to be object, array given
on line 81 of Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php

I'm guessing that if hydration is supposed to "just work" the parameter would be an object of the MyEmbeddable class?

So either this is still an issue or I'm doing it wrong...

(using ZF3 forms, DoctrineModule 2.1.3 and ORMModule 2.1.2)...

[driehle]

@TomHAnderson, @bitwombat: Unfortunatly, this issue is not resolved. I am currently using doctrine-module 2.1.7. The fix suggested in #475 however works!

In #475 @Bilge questioned, whether it is a good idea to check for . in the field name and suggested to query the metadata. I looked into this, but Doctrine's ClassMetadata does not provide a method to do so. getFieldNames() provides the field names (with . included for embedded fields) and getAssociationNames() provides the association names. Other methods are not provided. Therefore, checking for . is currently the only solution.

This implies that we cannot have a . in a field name. To me, this does not look like a problem, since PHP does not support . in the name of a member variable anyways. And as the field names actually refer to PHP class members (and not field names in the database), checking for . should be safe.

[Bilge]

@driehle Your observation that PHP does not permit . in field names is irrelevant because the . represents a boundary between two fields represented by two distinct classes. That is, foo.bar represents two separate fields, foo and bar belonging to two separate classes.

[driehle]

@Bilge Yes, and therefore, it is safe to split up the field name on the dot to separate the classes. Or am I mistaking something? In #475 you wrote:

How can it be adequate to just check if the field name contains a .? Surely this would break if I create a field with a dot in its name.

To my understanding you cannot create a field with a dot in its name, unless they are in two separate classes. If they are in two separate classes, the hydrator needs to look at the dot. And there again, the solution provided by @prolic seems to work quite well.

[Bilge]

Just because you observed that a Mongo field name maps to a PHP field name by default does not change the fact that they do not have to be mirrored. ODM provides a @name annotation to override the Mongo name mapped to the PHP backing field. Perhaps you missed this fact.

[driehle]

Ok, I am an ORM user, not ODM, so maybe that's way. So what is your solution to fix this issue? As said, ClassMetadata does not provide any information on whether a field is an embeddable or not. Here is a short example:

/** @ORM\Entity */
class User
{
    /** @ORM\Id */
    private $id;

    /** @ORM\Column(type="string", nullable=false) */
    private $name;

    /** @ORM\Embedded(class="Address") */
    private $address;
}

/** @ORM\Embeddable() */
class Address
{
    /** @ORM\Column(type="string", nullable=false) */
    private $street;

    /** @ORM\Column(type="string", nullable=false) */
    private $houseNumber;

    /** @ORM\Column(type="string", nullable=false) */
    private $postalCode;

    /** @ORM\Column(type="string", nullable=false) */
    private $city;

    /** @ORM\Column(type="string", nullable=false) */
    private $country;
}

The interesting thing is, that hydrateByValue() works as expected, while extractByValue() does not work. For my Zend forms this means that saving the values entered into the form works (they are hydrated into the entity and then persisted to database), while popluating the form with the current values does not work - the form fields of Address are empty when $form->bind($user) is called.

In DoctrineObject, a call to $this->metadata->getFieldNames() returns:

array(8) {
  [0]=>
  string(2) "id"
  [1]=>
  string(4) "name"
  [3]=>
  string(14) "address.street"
  [4]=>
  string(19) "address.houseNumber"
  [5]=>
  string(18) "address.postalCode"
  [6]=>
  string(12) "address.city"
  [7]=>
  string(15) "address.country"
}

And a call to $this->metadata->getAssociationNames() returns an empty array.