OneToOne cascade persist throws exception #5590

New Issue

admin · 2026-01-22T15:12:05+01:00

admin commented

2026-01-22 15:12:05 +01:00

Originally created by @boesing on GitHub (Jun 26, 2017).

Originally assigned to: @Ocramius on GitHub.

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.

Originally created by @boesing on GitHub (Jun 26, 2017). Originally assigned to: @Ocramius on GitHub. 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.

admin added the Bug Incomplete labels 2026-01-22 15:12:05 +01:00

admin closed this issue

2026-01-22 15:12:05 +01:00

admin commented

2026-01-22 15:12:06 +01:00

@Ocramius commented on GitHub (Jun 26, 2017):

Is it really the first statement throwing an exception here?

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

Can we eventually have a test case?

@Ocramius commented on GitHub (Jun 26, 2017): Is it really the first statement throwing an exception here? ```php $entityManager->persist($entity); // Throws exception... $entityManager->flush(); ``` Can we eventually have a test case?

admin commented

2026-01-22 15:12:06 +01:00

@lcobucci commented on GitHub (Jun 26, 2017):

@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.

@lcobucci commented on GitHub (Jun 26, 2017): @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.

admin commented

2026-01-22 15:12:07 +01:00

@boesing commented on GitHub (Jun 26, 2017):

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

@boesing commented on GitHub (Jun 26, 2017): @lcobucci The problem is, that we are not using PHP 7.1 yet... :/

admin commented

2026-01-22 15:12:08 +01:00

@lcobucci commented on GitHub (Jun 26, 2017):

@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 fc67b398a1 all the tests were working and PHP 7.0 was still supported). Please mind the emphasis on temporary 😂

@lcobucci commented on GitHub (Jun 26, 2017): @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 😂

admin commented

2026-01-22 15:12:08 +01:00

@Ocramius commented on GitHub (Jun 28, 2017):

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.

@Ocramius commented on GitHub (Jun 28, 2017): 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.

admin referenced this issue

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

[PR #5590] Fix discriminator column defaults #9656

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#5590