Removing one side of BiDi 1-1 relation throws #7409

New Issue

Open

opened 2026-01-22 15:51:21 +01:00 by admin · 9 comments

admin commented 2026-01-22 15:51:21 +01:00

Owner

Copy Link

Originally created by @duzenko on GitHub (Aug 22, 2024).

Bug Report

Q	A
BC Break	no
Version	2.19.6

Summary

I have added an inverseBy field to an existing entity class so as to use it in the BiDi 1-1 fashion. The DB structure did not change. The setup is similar to the example given at https://www.doctrine-project.org/projects/doctrine-orm/en/2.19/reference/association-mapping.html#one-to-one-bidirectional.
After this, under certain scenarios, deleting an entity throws an Exception.
Specifically, the entities are loaded via a DQL query:

		$dq = 'SELECT e, ec FROM ' . \E5\Entity\EventConfirmation::class . ' ec JOIN ec.event e WHERE ec.user = :user AND e.type = :type';
		$query = $this->getEntityManager()->createQuery( $dq )
				->setParameter( 'type', $type )
				->setParameter( 'user', $user );

		return $query->getOneOrNullResult();

This returns a nested object structure as expected:

After removing the $confirmation entity the structure becomes instable:

		$em->remove( $confirmation );
		$em->flush();

When I try commit the transaction after this, I get an exception:

Doctrine\ORM\ORMInvalidArgumentException: A new entity was found through the relationship 'E5\Entity\Event#confirmation' that was not configured to cascade persist operatio
ns for entity: E5\Entity\EventConfirmation@282. To solve this issue: Either explicitly call EntityManager#persist() on this unknown entity or configure cascade persist this
 association in the mapping for example @ManyToOne(..,cascade={"persist"}). If you cannot find out which entity causes the problem implement 'E5\Entity\EventConfirmation#__toString()' to get a clue. in /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/ORMInvalidArgumentException.php:103
Stack trace:
#0 /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/UnitOfWork.php(3856): Doctrine\ORM\ORMInvalidArgumentException::newEntitiesFoundThroughRelationships()     
#1 /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/UnitOfWork.php(417): Doctrine\ORM\UnitOfWork->assertThatThereAreNoUnintentionallyNonPersistedAssociations()#2 /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/EntityManager.php(403): Doctrine\ORM\UnitOfWork->commit()
#3 /media/sf_Remote/main-web-application/E4/C/Admin/Casher.php(209): Doctrine\ORM\EntityManager->flush()
#4 /media/sf_Remote/main-web-application/E4/C/Admin/Casher.php(190): C_Admin_Casher::eventIdentified()
#5 /media/sf_Remote/main-web-application/E8/feature/user/UserService.php(287): C_Admin_Casher::emailIdentifiedSend()
#6 /media/sf_Remote/main-web-application/E8/feature/onboarding/Service.php(84): E8\feature\user\UserService->sendIdentifiedMail()
#7 /media/sf_Remote/main-web-application/scripts/lib/dev.php(22): E8\feature\onboarding\Service->approveIdentificationDocument()
#8 /media/sf_Remote/main-web-application/scripts/cli.php(27): include_once('...')
#9 {main}

Which means that Doctrine is trying to persist the confirmation entity back to the DB.
This is the opposite to what the code did before successfully (before the additing of the inversedBy confirmation field in the Event entity.

Current behavior

Throws

How to reproduce

Delete the owner side of a BiDi 1-1 relation and commit.

Expected behavior

Delete successful. The inversed side changes to null.

Originally created by @duzenko on GitHub (Aug 22, 2024). ### Bug Report <!-- Fill in the relevant information below to help triage your issue. --> | Q | A |------------ | ------ | BC Break | no | Version | 2.19.6 #### Summary I have added an `inverseBy` field to an existing entity class so as to use it in the BiDi 1-1 fashion. The DB structure did not change. The setup is similar to the example given at https://www.doctrine-project.org/projects/doctrine-orm/en/2.19/reference/association-mapping.html#one-to-one-bidirectional. After this, under certain scenarios, deleting an entity throws an Exception. Specifically, the entities are loaded via a DQL query: ``` $dq = 'SELECT e, ec FROM ' . \E5\Entity\EventConfirmation::class . ' ec JOIN ec.event e WHERE ec.user = :user AND e.type = :type'; $query = $this->getEntityManager()->createQuery( $dq ) ->setParameter( 'type', $type ) ->setParameter( 'user', $user ); return $query->getOneOrNullResult(); ``` This returns a nested object structure as expected:  After removing the `$confirmation` entity the structure becomes instable: ``` $em->remove( $confirmation ); $em->flush(); ```  When I try commit the transaction after this, I get an exception: ``` Doctrine\ORM\ORMInvalidArgumentException: A new entity was found through the relationship 'E5\Entity\Event#confirmation' that was not configured to cascade persist operatio ns for entity: E5\Entity\EventConfirmation@282. To solve this issue: Either explicitly call EntityManager#persist() on this unknown entity or configure cascade persist this association in the mapping for example @ManyToOne(..,cascade={"persist"}). If you cannot find out which entity causes the problem implement 'E5\Entity\EventConfirmation#__toString()' to get a clue. in /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/ORMInvalidArgumentException.php:103 Stack trace: #0 /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/UnitOfWork.php(3856): Doctrine\ORM\ORMInvalidArgumentException::newEntitiesFoundThroughRelationships() #1 /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/UnitOfWork.php(417): Doctrine\ORM\UnitOfWork->assertThatThereAreNoUnintentionallyNonPersistedAssociations()#2 /media/sf_Remote/main-web-application/vendor/doctrine/orm/src/EntityManager.php(403): Doctrine\ORM\UnitOfWork->commit() #3 /media/sf_Remote/main-web-application/E4/C/Admin/Casher.php(209): Doctrine\ORM\EntityManager->flush() #4 /media/sf_Remote/main-web-application/E4/C/Admin/Casher.php(190): C_Admin_Casher::eventIdentified() #5 /media/sf_Remote/main-web-application/E8/feature/user/UserService.php(287): C_Admin_Casher::emailIdentifiedSend() #6 /media/sf_Remote/main-web-application/E8/feature/onboarding/Service.php(84): E8\feature\user\UserService->sendIdentifiedMail() #7 /media/sf_Remote/main-web-application/scripts/lib/dev.php(22): E8\feature\onboarding\Service->approveIdentificationDocument() #8 /media/sf_Remote/main-web-application/scripts/cli.php(27): include_once('...') #9 {main} ``` Which means that Doctrine is trying to persist the `confirmation` entity back to the DB. This is the opposite to what the code did before successfully (before the additing of the `inversedBy confirmation` field in the `Event` entity. #### Current behavior Throws #### How to reproduce Delete the owner side of a BiDi 1-1 relation and commit. #### Expected behavior Delete successful. The inversed side changes to null.

admin commented 2026-01-22 15:51:22 +01:00

Author

Owner

Copy Link

@duzenko commented on GitHub (Aug 22, 2024):

Relevant field definitions:

class EventConfirmation {
...
	/**
	 * @ORM\OneToOne(targetEntity="Event", inversedBy="confirmation")
	 * @JoinColumn(name="event", referencedColumnName="id")
	 */
	private ?Event $event;

This was added (along with inversedBy above) before the bug manifested:

class Event {
...
	/**
	 * @OneToOne(targetEntity="EventConfirmation", mappedBy="event")
	 */
	private ?EventConfirmation $confirmation;

@duzenko commented on GitHub (Aug 22, 2024): Relevant field definitions: ``` class EventConfirmation { ... /** * @ORM\OneToOne(targetEntity="Event", inversedBy="confirmation") * @JoinColumn(name="event", referencedColumnName="id") */ private ?Event $event; ``` This was added (along with `inversedBy` above) before the bug manifested: ``` class Event { ... /** * @OneToOne(targetEntity="EventConfirmation", mappedBy="event") */ private ?EventConfirmation $confirmation; ```

admin commented 2026-01-22 15:51:23 +01:00

Author

Owner

Copy Link

@duzenko commented on GitHub (Aug 22, 2024):

It seems that changing SELECT e, ec FROM to SELECT ec FROM helps in this particular case as it changes the type of event field from Entity to Proxy. However in general this kind of breakage should not occur at all.

@duzenko commented on GitHub (Aug 22, 2024): It seems that changing `SELECT e, ec FROM` to `SELECT ec FROM` helps in this particular case as it changes the type of `event` field from Entity to Proxy. However in general this kind of breakage should not occur at all.

admin commented 2026-01-22 15:51:23 +01:00

Author

Owner

Copy Link

@duzenko commented on GitHub (Sep 6, 2024):

It would be great to get some feedback regarding this
The bug also manifests with proxy objects after they get initialized

		$em = phpVirtualMachine()->getEntityManager();

		$eventConfirmations = $em->getRepository( \E5\Entity\EventConfirmation::class )->findBy( [ 'user' => $user ] );

		foreach( $eventConfirmations as $eventConfirmation ) {
			if( $eventConfirmation->getEvent()->getType() != $type ) {
				continue;
			}

			// now delete eventConfirmation will throw
		}

@duzenko commented on GitHub (Sep 6, 2024): It would be great to get some feedback regarding this The bug also manifests with proxy objects after they get initialized ``` $em = phpVirtualMachine()->getEntityManager(); $eventConfirmations = $em->getRepository( \E5\Entity\EventConfirmation::class )->findBy( [ 'user' => $user ] ); foreach( $eventConfirmations as $eventConfirmation ) { if( $eventConfirmation->getEvent()->getType() != $type ) { continue; } // now delete eventConfirmation will throw } ```

admin commented 2026-01-22 15:51:23 +01:00

Author

Owner

Copy Link

@greg0ire commented on GitHub (Sep 6, 2024):

Which means that Doctrine is trying to persist the confirmation entity back to the DB.

I wouldn't be so sure.

Looking at the stack trace, we can see that we are here:

cfc0655a1c/src/UnitOfWork.php (L353-L369)

So, directly inside commit(). I think you were mislead into thinking it has to do with persistence because of the error message.

I think you should debug further as to why this entity is considered new, but before that, have you validated your schema? I find it suspicious that such a big bug with what appears to be a pretty common situation happens at all.

You could also try reproducing it with a test.

@greg0ire commented on GitHub (Sep 6, 2024): > Which means that Doctrine is trying to persist the confirmation entity back to the DB. I wouldn't be so sure. Looking at the stack trace, we can see that we are here: https://github.com/doctrine/orm/blob/cfc0655a1c9b5ffd5506172cb7642b6090aa5f7e/src/UnitOfWork.php#L353-L369 So, directly inside `commit()`. I think you were mislead into thinking it has to do with persistence because of the error message. I think you should debug further as to why this entity is considered new, but before that, have you validated your schema? I find it suspicious that such a big bug with what appears to be a pretty common situation happens at all. You could also try reproducing it with a test.

admin commented 2026-01-22 15:51:23 +01:00

Author

Owner

Copy Link

@duzenko commented on GitHub (Sep 6, 2024):

@greg0ire Do you have a test already that deletes an entity on the owner side of a BiDi relation? I'd think no, which is why it was not noticed
And I don't think that deleting a BiDi owner (with a second flush after that) is pretty common
There is a chance that I'm doing something wrong, but I'd like to hear from you first
Note that commit is not necessary. It can be a second flush as well.

@duzenko commented on GitHub (Sep 6, 2024): @greg0ire Do you have a test already that deletes an entity on the owner side of a BiDi relation? I'd think no, which is why it was not noticed And I don't think that deleting a BiDi owner (with a second flush after that) is pretty common There is a chance that I'm doing something wrong, but I'd like to hear from you first Note that `commit` is not necessary. It can be a second `flush` as well.

admin commented 2026-01-22 15:51:23 +01:00

Author

Owner

Copy Link

@duzenko commented on GitHub (Sep 6, 2024):

@greg0ire This reproduced the error reliably for me

<?php
// bootstrap.php
use Doctrine\DBAL\DriverManager;
use Doctrine\ORM\EntityManager;
use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\JoinColumn;
use Doctrine\ORM\Mapping\OneToOne;
use Doctrine\ORM\ORMSetup;
use Doctrine\ORM\Mapping as ORM;

require_once "vendor/autoload.php";

#[Entity]
class Customer {
	#[ORM\Id]
	#[ORM\Column( type: 'integer' )]
	#[ORM\GeneratedValue]
	private int|null $id = null;

	/** One Customer has One Cart. */
	#[OneToOne( targetEntity: Cart::class, mappedBy: 'customer' )]
	public Cart|null $cart = null;

	#[ORM\Column( type: 'string' )]
	private string $name = 'qwe';

	public function getName(): string {
		return $this->name;
	}

	public function setName( string $name ): void {
		$this->name = $name;
	}
}

#[Entity]
class Cart {
	#[ORM\Id]
	#[ORM\Column( type: 'integer' )]
	#[ORM\GeneratedValue]
	public int|null $id = null;

	/** One Cart has One Customer. */
	#[OneToOne( targetEntity: Customer::class, inversedBy: 'cart' )]
	#[JoinColumn( name: 'customer_id', referencedColumnName: 'id' )]
	public Customer|null $customer = null;

}

unlink( 'db.sqlite' );
$database = new SQLite3( 'db.sqlite' );
$database->query( 'CREATE TABLE if not exists Cart (
    id integer PRIMARY KEY,
    customer_id INT DEFAULT NULL
);
CREATE TABLE if not exists Customer (
    id integer PRIMARY KEY,
    name varchar DEFAULT NULL
);' );

// Create a simple "default" Doctrine ORM configuration for Attributes
$config = ORMSetup::createAttributeMetadataConfiguration(
	paths: [],
	isDevMode: true,
);

// configuring the database connection
$connection = DriverManager::getConnection( [
	'driver' => 'pdo_sqlite',
	'path' => __DIR__ . '/db.sqlite',
], $config );

// obtaining the entity manager
$entityManager = new EntityManager( $connection, $config );

//$schemaTool = new \Doctrine\ORM\Tools\SchemaTool($entityManager);
//$classes = $entityManager->getMetadataFactory()->getAllMetadata();
//$schemaTool->createSchema($classes);

$cart = new Cart();
$cart->customer = new Customer();
$entityManager->persist( $cart->customer );
$entityManager->persist( $cart );
$entityManager->flush();
$entityManager->clear(); // simulate separate run

$cart = $entityManager->find( Cart::class, $cart->id );
$cart->customer->getName(); // initialize proxy
$entityManager->remove( $cart );
$entityManager->flush();

$cusomer = $entityManager->getRepository( Customer::class )->findAll()[ 0 ];
$cusomer->setName( 'asd' );
$entityManager->flush(); // throws here

echo 'OK', PHP_EOL;

Output

"[sshConfig://a@192.168.52.3:22 key]:/usr/bin/php" -dxdebug.mode=debug -dxdebug.client_port=9003 -dxdebug.client_host=192.168.52.1 /media/sf_Remote/test/bootstrap.php
PHP Fatal error:  Uncaught Doctrine\ORM\ORMInvalidArgumentException: A new entity was found through the relationship 'Customer#cart' that was not configured to cascade persist operations for entity: Cart@99. To solve this issue: Either explicitly call EntityManager#persist() on this unknown entity or configure cascade persist this association in the mapping for example @ManyToOne(..,cascade={"persist"}). If you cannot find out which entity causes the problem implement 'Cart#__toString()' to get a clue. in /media/sf_Remote/test/vendor/doctrine/orm/src/ORMInvalidArgumentException.php:103
Stack trace:
#0 /media/sf_Remote/test/vendor/doctrine/orm/src/UnitOfWork.php(3856): Doctrine\ORM\ORMInvalidArgumentException::newEntitiesFoundThroughRelationships()
#1 /media/sf_Remote/test/vendor/doctrine/orm/src/UnitOfWork.php(417): Doctrine\ORM\UnitOfWork->assertThatThereAreNoUnintentionallyNonPersistedAssociations()
#2 /media/sf_Remote/test/vendor/doctrine/orm/src/EntityManager.php(403): Doctrine\ORM\UnitOfWork->commit()
#3 /media/sf_Remote/test/bootstrap.php(94): Doctrine\ORM\EntityManager->flush()
#4 {main}
  thrown in /media/sf_Remote/test/vendor/doctrine/orm/src/ORMInvalidArgumentException.php on line 103

Process finished with exit code 255

@duzenko commented on GitHub (Sep 6, 2024): @greg0ire This reproduced the error reliably for me ```php <?php // bootstrap.php use Doctrine\DBAL\DriverManager; use Doctrine\ORM\EntityManager; use Doctrine\ORM\Mapping\Entity; use Doctrine\ORM\Mapping\JoinColumn; use Doctrine\ORM\Mapping\OneToOne; use Doctrine\ORM\ORMSetup; use Doctrine\ORM\Mapping as ORM; require_once "vendor/autoload.php"; #[Entity] class Customer { #[ORM\Id] #[ORM\Column( type: 'integer' )] #[ORM\GeneratedValue] private int|null $id = null; /** One Customer has One Cart. */ #[OneToOne( targetEntity: Cart::class, mappedBy: 'customer' )] public Cart|null $cart = null; #[ORM\Column( type: 'string' )] private string $name = 'qwe'; public function getName(): string { return $this->name; } public function setName( string $name ): void { $this->name = $name; } } #[Entity] class Cart { #[ORM\Id] #[ORM\Column( type: 'integer' )] #[ORM\GeneratedValue] public int|null $id = null; /** One Cart has One Customer. */ #[OneToOne( targetEntity: Customer::class, inversedBy: 'cart' )] #[JoinColumn( name: 'customer_id', referencedColumnName: 'id' )] public Customer|null $customer = null; } unlink( 'db.sqlite' ); $database = new SQLite3( 'db.sqlite' ); $database->query( 'CREATE TABLE if not exists Cart ( id integer PRIMARY KEY, customer_id INT DEFAULT NULL ); CREATE TABLE if not exists Customer ( id integer PRIMARY KEY, name varchar DEFAULT NULL );' ); // Create a simple "default" Doctrine ORM configuration for Attributes $config = ORMSetup::createAttributeMetadataConfiguration( paths: [], isDevMode: true, ); // configuring the database connection $connection = DriverManager::getConnection( [ 'driver' => 'pdo_sqlite', 'path' => __DIR__ . '/db.sqlite', ], $config ); // obtaining the entity manager $entityManager = new EntityManager( $connection, $config ); //$schemaTool = new \Doctrine\ORM\Tools\SchemaTool($entityManager); //$classes = $entityManager->getMetadataFactory()->getAllMetadata(); //$schemaTool->createSchema($classes); $cart = new Cart(); $cart->customer = new Customer(); $entityManager->persist( $cart->customer ); $entityManager->persist( $cart ); $entityManager->flush(); $entityManager->clear(); // simulate separate run $cart = $entityManager->find( Cart::class, $cart->id ); $cart->customer->getName(); // initialize proxy $entityManager->remove( $cart ); $entityManager->flush(); $cusomer = $entityManager->getRepository( Customer::class )->findAll()[ 0 ]; $cusomer->setName( 'asd' ); $entityManager->flush(); // throws here echo 'OK', PHP_EOL; ``` Output ``` "[sshConfig://a@192.168.52.3:22 key]:/usr/bin/php" -dxdebug.mode=debug -dxdebug.client_port=9003 -dxdebug.client_host=192.168.52.1 /media/sf_Remote/test/bootstrap.php PHP Fatal error: Uncaught Doctrine\ORM\ORMInvalidArgumentException: A new entity was found through the relationship 'Customer#cart' that was not configured to cascade persist operations for entity: Cart@99. To solve this issue: Either explicitly call EntityManager#persist() on this unknown entity or configure cascade persist this association in the mapping for example @ManyToOne(..,cascade={"persist"}). If you cannot find out which entity causes the problem implement 'Cart#__toString()' to get a clue. in /media/sf_Remote/test/vendor/doctrine/orm/src/ORMInvalidArgumentException.php:103 Stack trace: #0 /media/sf_Remote/test/vendor/doctrine/orm/src/UnitOfWork.php(3856): Doctrine\ORM\ORMInvalidArgumentException::newEntitiesFoundThroughRelationships() #1 /media/sf_Remote/test/vendor/doctrine/orm/src/UnitOfWork.php(417): Doctrine\ORM\UnitOfWork->assertThatThereAreNoUnintentionallyNonPersistedAssociations() #2 /media/sf_Remote/test/vendor/doctrine/orm/src/EntityManager.php(403): Doctrine\ORM\UnitOfWork->commit() #3 /media/sf_Remote/test/bootstrap.php(94): Doctrine\ORM\EntityManager->flush() #4 {main} thrown in /media/sf_Remote/test/vendor/doctrine/orm/src/ORMInvalidArgumentException.php on line 103 Process finished with exit code 255 ```

admin commented 2026-01-22 15:51:24 +01:00

Author

Owner

Copy Link

@greg0ire commented on GitHub (Sep 6, 2024):

Is it a minimal reproducer? For instance, is the JoinColumn attribute necessary to reproduce the issue? Also, when I wrote "You could also try reproducing it with a test." I meant a PHPUnit test that you would add to the doctrine/orm test suite.

@greg0ire commented on GitHub (Sep 6, 2024): Is it a minimal reproducer? For instance, is the `JoinColumn` attribute necessary to reproduce the issue? Also, when I wrote "You could also try reproducing it with a test." I meant a PHPUnit test that you would add to the `doctrine/orm` test suite.

admin commented 2026-01-22 15:51:25 +01:00

Author

Owner

Copy Link

@duzenko commented on GitHub (Sep 7, 2024):

Is it a minimal reproducer? For instance, is the JoinColumn attribute necessary to reproduce the issue?

How would I know if it is necessary? I took this code from your official docs at https://www.doctrine-project.org/projects/doctrine-orm/en/2.19/reference/association-mapping.html.

Also, when I wrote "You could also try reproducing it with a test." I meant a PHPUnit test that you would add to the doctrine/orm test suite.

Sorry, does it mean the a PHP file that you can run from CLI or IDE directly is not acepted as reproduction case? I'd think that you could convert it to a PHPUnit test in less than 5 minutes if you were interested in this bug, without the lengthy procedure of me creating a PR just for it to chill in the waiting list with another 298 PRs you already have.
My originial post had less code for which you advised to "debug further" on my side implying that I'm not using Doctrine right.
I don't think I should be getting any more of these "try harder" responses at this point

@duzenko commented on GitHub (Sep 7, 2024): > Is it a minimal reproducer? For instance, is the JoinColumn attribute necessary to reproduce the issue? How would I know if it is necessary? I took this code from your official docs at https://www.doctrine-project.org/projects/doctrine-orm/en/2.19/reference/association-mapping.html. > Also, when I wrote "You could also try reproducing it with a test." I meant a PHPUnit test that you would add to the doctrine/orm test suite. Sorry, does it mean the a PHP file that you can run from CLI or IDE directly is not acepted as reproduction case? I'd think that you could convert it to a PHPUnit test in less than 5 minutes if you were interested in this bug, without the lengthy procedure of me creating a PR just for it to chill in the waiting list with another 298 PRs you already have. My originial post had less code for which you advised to "debug further" on my side implying that I'm not using Doctrine right. I don't think I should be getting any more of these "try harder" responses at this point

admin commented 2026-01-22 15:51:25 +01:00

Author

Owner

Copy Link

@greg0ire commented on GitHub (Sep 7, 2024):

Let me focus on the 298 PRs first (more actually if you can't other repos), and I will get back to you.

@greg0ire commented on GitHub (Sep 7, 2024): Let me focus on the 298 PRs first (more actually if you can't other repos), and I will get back to you.

admin referenced this issue 2026-01-22 16:07:39 +01:00

[PR #7409] Implements the feature request in issue #7408 #10474

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

3.6.x

2.20.x

dependabot/github_actions/2.20.x/doctrine/dot-github/dot-github/workflows/composer-lint.yml-14.0.0

3.7.x

4.0.x

2.21.x

old-prototype-3.x

3.6.2

3.6.1

3.6.0

2.20.9

3.5.8

3.5.7

3.5.6

3.5.5

2.20.8

3.5.4

3.5.3

2.20.7

3.5.2

2.20.6

3.5.1

3.5.0

3.4.4

3.4.3

3.4.2

2.20.5

3.4.1

3.4.0

3.3.4

2.20.4

3.3.3

2.20.3

3.3.2

2.20.2

3.3.1

2.20.1

3.3.0

3.2.3

2.20.0

2.19.8

3.2.2

2.19.7

3.2.1

2.19.6

3.2.0

3.1.4

3.1.3

2.19.5

3.1.2

2.19.4

3.1.1

2.19.3

2.19.2

2.19.1

3.1.0

2.19.0

3.0.3

2.18.3

3.0.2

2.18.2

3.0.1

2.18.1

3.0.0

2.18.0

2.17.5

3.0.0-RC1

2.17.4

2.17.3

2.17.2

2.17.1

3.0.0-beta2

2.17.0

2.16.3

3.0.0-beta1

2.16.2

2.16.1

2.16.0

2.15.5

2.15.4

2.15.3

2.15.2

2.15.1

2.15.0

2.14.3

2.14.2

2.14.1

2.14.0

2.13.5

2.13.4

2.13.3

2.13.2

2.13.1

2.13.0

2.12.4

2.12.3

2.12.2

2.12.1

2.12.0

2.11.3

2.11.2

2.11.1

2.11.0

2.10.5

2.10.4

2.10.3

2.10.2

2.10.1

2.10.0

2.9.6

2.9.5

2.9.4

2.9.3

2.9.2

2.9.1

2.9.0

2.8.5

2.8.4

2.8.3

2.8.2

2.8.1

2.8.0

2.7.5

2.7.4

v2.7.3

v2.7.2

v2.7.1

v2.7.0

v2.6.6

v2.6.5

v2.6.4

v2.6.3

v2.6.2

v2.6.1

v2.6.0

v2.5.14

v2.5.13

v2.5.12

v2.5.11

v2.5.10

v2.5.9

v2.5.8

v2.5.7

v2.5.6

v2.5.5

v2.5.4

v2.5.3

v2.5.2

v2.4.8

v2.5.1

v2.5.0

v2.5.0-RC2

v2.5.0-RC1

v2.5.0-beta1

v2.5.0-alpha2

v2.5.0-alpha1

v2.4.7

v2.4.6

v2.4.5

v2.4.4

v2.4.3

v2.3.6

v2.4.2

2.3.5

v2.4.1

v2.4.0

2.4.0-RC2

2.4.0-RC1

2.4.0-BETA2

2.3.4

2.3.3

2.4.0-BETA1

2.3.2

2.3.1

2.3.0

2.3.0-RC4

2.3.0-RC3

2.3.0-RC2

2.2.3

2.3.0-RC1

2.3.0-BETA1

2.1.7

2.2.2

2.2.1

2.1.6

2.2.0

2.2.0-RC1

2.2.0-BETA2

2.2.0-BETA1

2.1.5

2.1.4

2.1.3

2.1.2

2.1.1

2.0.7

2.1.0

2.1.0RC3

2.1.0RC2

2.1.0RC1

2.0.6

2.1.0BETA1

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

2.0.0RC2

2.0.0RC1

2.0.0-BETA4

2.0.0-BETA3

2.0.0-BETA2

2.0.0-BETA1

Labels

Clear labels

BC Break

Bug

Can't Fix

Deprecation

Documentation

DQL

Duplicate

Failing Test

Hacktoberfest

Improvement

Improvement

Incomplete

Invalid

Missing Tests

New Feature

PR Created

pull-request

Mirrored from GitHub Pull Request

Question

Regression

Status: Waiting feedback

Waiting feedback

WIP

Won't Fix

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

admin

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7409