Orm: OneToOne cascade persist throws exception

[boesing]

Hey there,

I have two relating entities:

/**
 * @ORM\Entity
 * @ORM\Table("foo")
 */
class A {
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    private $id;

    /**
     * @ORM\OneToOne(targetEntity="B", mappedBy="ref", cascade={"persist"})
     */
    private $ref;

    public function getRef() {
         return $this->ref;
    }

    public function setRef(B $reference) {
         $this->ref = $reference;
         if ($reference->getRef() !== $this) {
              $reference->setRef($this);
         }
    }
}

/**
 * @ORM\Entity
 * @ORM\Table("bar")
 */
class B {

    /**
     * @ORM\OneToOne(targetEntity="A", inversedBy="ref")
     * @ORM\JoinColumn(name="ref_id", referencedColumnName="id")
     */
    private $ref;

    public function getRef() {
         return $this->ref;
    }

    public function setRef(A $reference) {
         $this->ref = $reference;
         if ($reference->getRef() !== $this) {
              $reference->setRef($this);
         }
    }
}

If I want to persist A like this, I get the exception, that there is no identifier value set yet (ofc not, I am actually persisting tho...):

$entity = new A;
$entity->setRef(new B);

$entityManager->persist($entity); // Throws exception...
$entityManager->flush();

The Problem is, that the Method \Doctrine\ORM\UnitOfWork::scheduleForInsert wants to create an identifier hash but since we did not flushed the entities yet, there aint any value other than null.

[Ocramius]

Is it really the first statement throwing an exception here?

$entityManager->persist($entity); // Throws exception...
$entityManager->flush();

Can we eventually have a test case?

[lcobucci]

@boesing @Ocramius this is definitely related to the refactoring of the commit order calculation that was done a couple years ago and which is just part of 2.6.x. Since the changes are quite complex to backport we decided to keep that only on master.

@boesing as I said on your PR, try to reproduce this against master. If you're unable, I do recommend you to start changing your application to be compatible with our next minor release.

[boesing]

@lcobucci The problem is, that we are not using PHP 7.1 yet... :/

[lcobucci]

@boesing I understand but this seems to be one of the edge cases that we couldn't backport and unfortunately if you want to use that mapping you would have to update.

If you don't manage to reproduce this on master, you could try to use a fixed commit on your composer.json to "solve" this until you upgrade your stack to PHP 7.1.
It's definitely not ideal but serves as a TEMPORARY workaround (at fc67b398a1efd3d61837778e2cda2d05a395778c all the tests were working and PHP 7.0 was still supported). Please mind the emphasis on temporary 😂

[Ocramius]

I closed this as incomplete on the PR, closing it here as well.

@boesing all we need is to test it against master on the repository. Due to the patches that landed in 2.6, we won't be able to fix this for 2.5 anymore, sorry.