[PR #10531] Add test: Commit order calculation must happen on the entity level #12434

New Issue

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

admin commented

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

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

State: closed
Merged: Yes

Add tests for entity insertion and deletion that require the commit order calculation to happen on the entity level. This demonstrates the necessity for the changes in #10547.

This PR contains two tests with carefully constructed entity relationships, where we have a non-nullable parent foreign key relationships between entities stored in the same table.

Class diagram:

classDiagram
    direction LR
    class A
    class B
    A --> B : parent
    B --|> A

Object graph:

graph LR;
    b1 --> b2;
    b2 --> a;
    b3 --> b2;

Situation before #10547

The commit order is computed by looking at the associations at the table (= class) level. Once the ordering of tables has been found, entities being mapped to the same table will be processed in the order they were given to persist() or remove().

That means only a particular ordering of persist() or remove() calls (see comment in the test) works:

For inserts, the order must be $a, $b2, $b1, $b3 (or ... $b3, $b1), for deletions $b1, $b3, $b2, $a.

Situation with entity-level commit order computation (as in #10547)

The ORM computes the commit order by considering associations at the entity level. It will be able to find a working order by itself.

**Original Pull Request:** https://github.com/doctrine/orm/pull/10531 **State:** closed **Merged:** Yes --- Add tests for entity insertion and deletion that require the commit order calculation to happen on the entity level. This demonstrates the necessity for the changes in #10547. This PR contains two tests with carefully constructed entity relationships, where we have a non-nullable `parent` foreign key relationships between entities stored in the same table. Class diagram: ```mermaid classDiagram direction LR class A class B A --> B : parent B --|> A ``` Object graph: ```mermaid graph LR; b1 --> b2; b2 --> a; b3 --> b2; ``` #### Situation before #10547 The commit order is computed by looking at the associations at the _table_ (= _class_) level. Once the ordering of _tables_ has been found, entities being mapped to the same table will be processed in the order they were given to `persist()` or `remove()`. That means only a particular ordering of `persist()` or `remove()` calls (see comment in the test) works: For inserts, the order must be `$a, $b2, $b1, $b3` (or `... $b3, $b1`), for deletions `$b1, $b3, $b2, $a`. #### Situation with entity-level commit order computation (as in #10547) The ORM computes the commit order by considering associations at the _entity_ level. It will be able to find a working order by itself.

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

admin closed this issue

2026-01-22 16:14:02 +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#12434