[PR #10566] Commit order for removals has to consider SET NULL, not nullable #12458

New Issue

admin · 2026-01-22T16:14:06+01:00

admin commented

2026-01-22 16:14:06 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/10566

State: closed
Merged: Yes

When computing the commit order for entity removals, we have to look out for @ORM\JoinColumn(onDelete="SET NULL") to find places where cyclic associations can be broken.

This is part of the efforts in #10547 to solve various commit-order related problems.

Background

The UoW computes a "commit order" to find the sequence in which tables shall be processed when inserting entities into the database or performing delete operations.

For the insert case, the ORM is able to schedule extra updates that will be performed after all entities have been inserted. Associations which are configured as @ORM\JoinColumn(nullable=true, ...) can be left as NULL in the database when performing the initial INSERT statements, and will be updated once all new entities have been written to the database. This can be used to break cyclic associations between entity instances.

For removals, the ORM does not currently implement up-front UPDATE statements to NULL out associations before DELETE statements are executed. That means when associations form a cycle, users have to configure @ORM\JoinColumn(onDelete="SET NULL", ...) on one of the associations involved. This transfers responsibility to the DBMS to break the cycle at that place.

But, we still have to perform the delete statements in an order that makes this happen early enough. This may be a different order than the one required for the insert case. We can find it only by looking at the onDelete behaviour. We must ignore the nullable property, which is irrelevant, since we do not even try to NULL anything.

Example

Assume three entity classes A, B, C. There are unidirectional one-to-one associations A -> B, B -> C, C -> A. All those associations are nullable= true.

Three entities $a, $b, $c are created from these respective classes and associations are set up.

All operations cascade at the ORM level. So we can test what happens when we start the operations at the three individual entities, but in the end, they will always involve all three of them.

Any insert order will work, so the improvements necessary to solve #10531 or #10532 are not needed here. Since all associations are between different tables, the current table-level computation is good enough.

For the removal case, only the A -> B association has onDelete="SET NULL". So, the only possible execution order is $b, $c, $a. We have to find that regardless of where we start the cascade operation.

The DBMS will set the A -> B association on $a to NULL when we remove $b. We can then remove $c since it is no longer being referred to, then $a.

These cases ask for the ORM to perform the extra update before the delete by itself, without DBMS-level support:

Extra bonus

This is what the DALL·E AI thinks it looks like when the UnitOfWork is sequencing entity deletions with cascade.

**Original Pull Request:** https://github.com/doctrine/orm/pull/10566 **State:** closed **Merged:** Yes --- When computing the commit order for entity removals, we have to look out for `@ORM\JoinColumn(onDelete="SET NULL")` to find places where cyclic associations can be broken. This is part of the efforts in #10547 to solve various commit-order related problems. #### Background The UoW computes a "commit order" to find the sequence in which tables shall be processed when inserting entities into the database or performing delete operations. For the insert case, the ORM is able to schedule _extra updates_ that will be performed after all entities have been inserted. Associations which are configured as `@ORM\JoinColumn(nullable=true, ...)` can be left as `NULL` in the database when performing the initial `INSERT` statements, and will be updated once all new entities have been written to the database. This can be used to break cyclic associations between entity instances. For removals, the ORM does not currently implement up-front `UPDATE` statements to `NULL` out associations before `DELETE` statements are executed. That means when associations form a cycle, users have to configure `@ORM\JoinColumn(onDelete="SET NULL", ...)` on one of the associations involved. This transfers responsibility to the DBMS to break the cycle at that place. _But_, we still have to perform the delete statements in an order that makes this happen early enough. This may be a _different_ order than the one required for the insert case. We can find it _only_ by looking at the `onDelete` behaviour. We must ignore the `nullable` property, which is irrelevant, since we do not even try to `NULL` anything. #### Example Assume three entity classes `A`, `B`, `C`. There are unidirectional one-to-one associations `A -> B`, `B -> C`, `C -> A`. All those associations are `nullable= true`. Three entities `$a`, `$b`, `$c` are created from these respective classes and associations are set up. All operations `cascade` at the ORM level. So we can test what happens when we start the operations at the three individual entities, but in the end, they will always involve all three of them. _Any_ insert order will work, so the improvements necessary to solve #10531 or #10532 are not needed here. Since all associations are between different tables, the current table-level computation is good enough. For the removal case, only the `A -> B` association has `onDelete="SET NULL"`. So, the only possible execution order is `$b`, `$c`, `$a`. We have to find that regardless of where we start the cascade operation. The DBMS will set the `A -> B` association on `$a` to `NULL` when we remove `$b`. We can then remove `$c` since it is no longer being referred to, then `$a`. #### Related cases These cases ask for the ORM to perform the extra update before the delete by itself, without DBMS-level support: * #5665 * #10548 #### Extra bonus This is what the DALL·E AI thinks it looks like when the UnitOfWork is sequencing entity deletions with cascade. ![DALL·E 2023-05-09 13 09 58](https://github.com/doctrine/orm/assets/1202333/7092610f-ab60-46e5-ae12-624f215e1aa4)

admin added the pull-request label 2026-01-22 16:14:06 +01:00

admin closed this issue

2026-01-22 16:14:07 +01:00

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

[PR #10566] Commit order for removals has to consider SET NULL, not nullable #12458

Background

Example

Related cases

Extra bonus

[PR #10566] Commit order for removals has to consider `SET NULL`, not `nullable` #12458