Unit of Work calculates unnecessary UPDATE queries for enum properties in cascaded collections #7059

New Issue

Closed

opened 2026-01-22 15:43:56 +01:00 by admin · 3 comments

admin commented 2026-01-22 15:43:56 +01:00

Owner

Copy Link

Originally created by @mbabker on GitHub (Oct 12, 2022).

Bug Report

Q	A
BC Break	no
Version	2.13.3

Summary

While troubleshooting performance issues in one of our Symfony 6.1 applications, we found a request where a large number of UPDATE queries were being made which were generally unrelated to the actual request, screenshot is from New Relic:

Except for the time_sold column (unrelated to this bug report, it's something I still need to debug), all of the changes in the UPDATE statements are touching columns that use backed enums in their mapping.

After debugging, I've found that this happens when persisting an entity that includes a "cascade persist" on a collection. When the unit of work calculates the change set with one of these entities loaded, it's computing the following change for one of these enum fields:

  [338] =>
  array(1) {
    'status' =>
    array(2) {
      [0] =>
      enum App\LotStatus::AVAILABLE : string("available");
      [1] =>
      string(9) "available"
    }
  }

Current behavior

Unit of Work calculates incorrect changes, causing unnecessary UPDATE statements during a transaction

How to reproduce

https://github.com/mbabker/enum-uow-bug includes the minimal reproducer I was able to build to represent this issue.

Ensuring you have sqlite available on your system, clone the repo and run the following commands:

php app.php orm:schema-tool:create
php app.php orm:schema-tool:update --force
php app.php app:seed-database
php app.php app:update-auction-name --auction-id=1 --name="Changed Name"

When the last command runs, it'll dump out the computed change set from the Unit of Work as well as the log records from the middleware:

array(3) {
  [342] =>
  array(3) {
    'name' =>
    array(2) {
      [0] =>
      string(13) "Testing Event"
      [1] =>
      string(12) "Changed Name"
    }
    'type' =>
    array(2) {
      [0] =>
      enum App\AuctionType::LIVE : string("live");
      [1] =>
      string(4) "live"
    }
    'status' =>
    array(2) {
      [0] =>
      enum App\AuctionStatus::ACTIVE : string("active");
      [1] =>
      string(6) "active"
    }
  }
  [338] =>
  array(1) {
    'status' =>
    array(2) {
      [0] =>
      enum App\LotStatus::AVAILABLE : string("available");
      [1] =>
      string(9) "available"
    }
  }
  [336] =>
  array(1) {
    'status' =>
    array(2) {
      [0] =>
      enum App\LotStatus::AVAILABLE : string("available");
      [1] =>
      string(9) "available"
    }
  }
}

DBAL Log Entries:
 * Connecting with parameters array{"driver":"pdo_sqlite","path":"/Volumes/Samsung T7/Sites/enum-uow-bug/db.sqlite"}
 * Executing statement: SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.type AS type_2, a0_.status AS status_3, l1_.id AS id_4, l1_.number AS number_5, l1_.title AS title_6, l1_.status AS status_7, l1_.auction_id AS auction_id_8 FROM Auction a0_ LEFT JOIN Lot l1_ ON a0_.id = l1_.auction_id WHERE a0_.id = ? (parameters: array{"1":"1"}, types: array{"1":2})
 * Beginning transaction
 * Executing statement: UPDATE Auction SET name = ?, type = ?, status = ? WHERE id = ? (parameters: array{"1":"Changed Name","2":"live","3":"active","4":1}, types: array{"1":2,"2":2,"3":2,"4":1})
 * Executing statement: UPDATE Lot SET status = ? WHERE id = ? (parameters: array{"1":"available","2":1}, types: array{"1":2,"2":1})
 * Executing statement: UPDATE Lot SET status = ? WHERE id = ? (parameters: array{"1":"available","2":2}, types: array{"1":2,"2":1})
 * Committing transaction

Expected behavior

Changes aren't detected for unchanged enum properties, the above reproducer should have the following log output:

DBAL Log Entries:
 * Connecting with parameters array{"driver":"pdo_sqlite","path":"/Volumes/Samsung T7/Sites/enum-uow-bug/db.sqlite"}
 * Executing statement: SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.type AS type_2, a0_.status AS status_3, l1_.id AS id_4, l1_.number AS number_5, l1_.title AS title_6, l1_.status AS status_7, l1_.auction_id AS auction_id_8 FROM Auction a0_ LEFT JOIN Lot l1_ ON a0_.id = l1_.auction_id WHERE a0_.id = ? (parameters: array{"1":"1"}, types: array{"1":2})
 * Beginning transaction
 * Executing statement: UPDATE Auction SET name = ? WHERE id = ? (parameters: array{"1":"Changed Name","2":1}, types: array{"1":2,"2":1})
 * Committing transaction

Originally created by @mbabker on GitHub (Oct 12, 2022). ### Bug Report <!-- Fill in the relevant information below to help triage your issue. --> | Q | A |------------ | ------ | BC Break | no | Version | 2.13.3 #### Summary While troubleshooting performance issues in one of our Symfony 6.1 applications, we found a request where a large number of UPDATE queries were being made which were generally unrelated to the actual request, screenshot is from New Relic:  Except for the `time_sold` column (unrelated to this bug report, it's something I still need to debug), all of the changes in the UPDATE statements are touching columns that use backed enums in their mapping. After debugging, I've found that this happens when persisting an entity that includes a "cascade persist" on a collection. When the unit of work calculates the change set with one of these entities loaded, it's computing the following change for one of these enum fields: ``` [338] => array(1) { 'status' => array(2) { [0] => enum App\LotStatus::AVAILABLE : string("available"); [1] => string(9) "available" } } ``` #### Current behavior Unit of Work calculates incorrect changes, causing unnecessary UPDATE statements during a transaction #### How to reproduce <!-- Provide steps to reproduce the bug. If possible, also add a code snippet with relevant configuration, entity mappings, DQL etc. Adding a failing Unit or Functional Test would help us a lot - you can submit one in a Pull Request separately, referencing this bug report. --> https://github.com/mbabker/enum-uow-bug includes the minimal reproducer I was able to build to represent this issue. Ensuring you have `sqlite` available on your system, clone the repo and run the following commands: ```sh php app.php orm:schema-tool:create php app.php orm:schema-tool:update --force php app.php app:seed-database php app.php app:update-auction-name --auction-id=1 --name="Changed Name" ``` When the last command runs, it'll dump out the computed change set from the Unit of Work as well as the log records from the middleware: ``` array(3) { [342] => array(3) { 'name' => array(2) { [0] => string(13) "Testing Event" [1] => string(12) "Changed Name" } 'type' => array(2) { [0] => enum App\AuctionType::LIVE : string("live"); [1] => string(4) "live" } 'status' => array(2) { [0] => enum App\AuctionStatus::ACTIVE : string("active"); [1] => string(6) "active" } } [338] => array(1) { 'status' => array(2) { [0] => enum App\LotStatus::AVAILABLE : string("available"); [1] => string(9) "available" } } [336] => array(1) { 'status' => array(2) { [0] => enum App\LotStatus::AVAILABLE : string("available"); [1] => string(9) "available" } } } ``` ``` DBAL Log Entries: * Connecting with parameters array{"driver":"pdo_sqlite","path":"/Volumes/Samsung T7/Sites/enum-uow-bug/db.sqlite"} * Executing statement: SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.type AS type_2, a0_.status AS status_3, l1_.id AS id_4, l1_.number AS number_5, l1_.title AS title_6, l1_.status AS status_7, l1_.auction_id AS auction_id_8 FROM Auction a0_ LEFT JOIN Lot l1_ ON a0_.id = l1_.auction_id WHERE a0_.id = ? (parameters: array{"1":"1"}, types: array{"1":2}) * Beginning transaction * Executing statement: UPDATE Auction SET name = ?, type = ?, status = ? WHERE id = ? (parameters: array{"1":"Changed Name","2":"live","3":"active","4":1}, types: array{"1":2,"2":2,"3":2,"4":1}) * Executing statement: UPDATE Lot SET status = ? WHERE id = ? (parameters: array{"1":"available","2":1}, types: array{"1":2,"2":1}) * Executing statement: UPDATE Lot SET status = ? WHERE id = ? (parameters: array{"1":"available","2":2}, types: array{"1":2,"2":1}) * Committing transaction ``` #### Expected behavior Changes aren't detected for unchanged enum properties, the above reproducer should have the following log output: ``` DBAL Log Entries: * Connecting with parameters array{"driver":"pdo_sqlite","path":"/Volumes/Samsung T7/Sites/enum-uow-bug/db.sqlite"} * Executing statement: SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.type AS type_2, a0_.status AS status_3, l1_.id AS id_4, l1_.number AS number_5, l1_.title AS title_6, l1_.status AS status_7, l1_.auction_id AS auction_id_8 FROM Auction a0_ LEFT JOIN Lot l1_ ON a0_.id = l1_.auction_id WHERE a0_.id = ? (parameters: array{"1":"1"}, types: array{"1":2}) * Beginning transaction * Executing statement: UPDATE Auction SET name = ? WHERE id = ? (parameters: array{"1":"Changed Name","2":1}, types: array{"1":2,"2":1}) * Committing transaction ```

admin closed this issue 2026-01-22 15:43:56 +01:00

admin commented 2026-01-22 15:43:56 +01:00

Author

Owner

Copy Link

@W0rma commented on GitHub (Oct 13, 2022):

Could that be related to https://github.com/doctrine/orm/pull/10088 ?

@W0rma commented on GitHub (Oct 13, 2022): Could that be related to https://github.com/doctrine/orm/pull/10088 ?

admin commented 2026-01-22 15:43:56 +01:00

Author

Owner

Copy Link

@mbabker commented on GitHub (Oct 13, 2022):

Possibly related, but I patched my repro locally and it's still giving the extra UPDATE queries with it applied.

@mbabker commented on GitHub (Oct 13, 2022): Possibly related, but I patched my repro locally and it's still giving the extra UPDATE queries with it applied.

admin commented 2026-01-22 15:43:57 +01:00

Author

Owner

Copy Link

@mbabker commented on GitHub (Nov 23, 2022):

Looks to be fixed on current 2.13 dev build.

@mbabker commented on GitHub (Nov 23, 2022): Looks to be fixed on current 2.13 dev build.

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