doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-03-23 22:42:18 +01:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

UnitOfWork still not right - probably Enum-related #7074

New Issue
Closed
opened 2026-01-22 15:44:09 +01:00 by admin · 8 comments
admin commented 2026-01-22 15:44:09 +01:00
Owner
Copy Link

Originally created by @ThomasLandauer on GitHub (Nov 24, 2022).

BC Break Report

Q A
BC Break yes
Version 2.13.2 and .3 and .4

Summary

I think I'm observing the same issue as https://github.com/doctrine/orm/issues/10124, but it wasn't fixed by 2.13.4, so I'm posting it separately.

I have a table with some thousand entries, and when I change a single one (through a Symfony form), all are getting "updated" (i.e. overwritten with their current values).

The last version, which really works for me, is 2.13.1.

2.13.2 introduced the error:

"Hearts,Clubs" is not a valid backing value for enum "App\Suit"

This was fixed in 2.13.3, but since then, persisting a single changed entity takes several minutes.

How to reproduce

I tried dd($this->getEntityManager()->getUnitOfWork());, but couldn't find any differences between the working and non-working versions - where should I look at to provide more information?

Originally created by @ThomasLandauer on GitHub (Nov 24, 2022). ### BC Break Report <!-- Fill in the relevant information below to help triage your issue. --> | Q | A |------------ | ------ | BC Break | yes | Version | 2.13.2 and .3 and .4 #### Summary I think I'm observing the same issue as https://github.com/doctrine/orm/issues/10124, but it wasn't fixed by 2.13.4, so I'm posting it separately. I have a table with some thousand entries, and when I change a single one (through a Symfony form), *all* are getting "updated" (i.e. overwritten with their current values). The last version, which really works for me, is 2.13.1. 2.13.2 introduced the error: > "Hearts,Clubs" is not a valid backing value for enum "App\Suit" This was fixed in 2.13.3, but since then, persisting a single changed entity takes several minutes. #### How to reproduce I tried `dd($this->getEntityManager()->getUnitOfWork());`, but couldn't find any differences between the working and non-working versions - where should I look at to provide more information?
admin closed this issue 2026-01-22 15:44:09 +01:00
admin commented 2026-01-22 15:44:10 +01:00
Author
Owner
Copy Link

@derrabus commented on GitHub (Nov 24, 2022):

Share a repository that reproduces the problem, please.

@derrabus commented on GitHub (Nov 24, 2022): Share a repository that reproduces the problem, please.
admin commented 2026-01-22 15:44:10 +01:00
Author
Owner
Copy Link

@michnovka commented on GitHub (Dec 7, 2022):

@ThomasLandauer I have some spare time to look into this issue, if you could provide a test (ideally) or a repo with the broken logic and steps to reproduce. Thanks

@michnovka commented on GitHub (Dec 7, 2022): @ThomasLandauer I have some spare time to look into this issue, if you could provide a test (ideally) or a repo with the broken logic and steps to reproduce. Thanks
admin commented 2026-01-22 15:44:11 +01:00
Author
Owner
Copy Link

@ThomasLandauer commented on GitHub (Dec 7, 2022):

Thanks for reminding - I just tried to reproduce this, but didn't succeed yet :-(

In my real project the same operation (form submission to persist 1 small change) takes:

  • v2.13.1: 3.5 seconds
  • v2.13.4: 12.5 seconds! However, the Symfony web toolbar shows a "total time" of 2300 ms, and a "query time" of 1700 ms (for 14 queries). So what's going on in the remaining 10 seconds?

When trying to reproduce it, my problem is that I don't know where to look at :-( So I'm only after the speed difference - but when running on a local machine with a small SQLite database, everything is quite fast...

Do you maybe have some hints for me about what I could dump?? Any "usual suspects"?

@ThomasLandauer commented on GitHub (Dec 7, 2022): Thanks for reminding - I just tried to reproduce this, but didn't succeed yet :-( In my real project the same operation (form submission to persist 1 small change) takes: * v2.13.1: 3.5 seconds * v2.13.4: 12.5 seconds! However, the Symfony web toolbar shows a "total time" of 2300 ms, and a "query time" of 1700 ms (for 14 queries). So what's going on in the remaining 10 seconds? When trying to reproduce it, my problem is that I don't know where to look at :-( So I'm only after the speed difference - but when running on a local machine with a small SQLite database, *everything* is quite fast... Do you maybe have some hints for me about what I could dump?? Any "usual suspects"?
admin commented 2026-01-22 15:44:11 +01:00
Author
Owner
Copy Link

@michnovka commented on GitHub (Dec 8, 2022):

So you are not certain they are all getting updated? You only assume that based on time it takes? Did u confirm with symfony debugger list of executed queries?

@michnovka commented on GitHub (Dec 8, 2022): So you are not certain they are all getting updated? You only assume that based on time it takes? Did u confirm with symfony debugger list of executed queries?
admin commented 2026-01-22 15:44:11 +01:00
Author
Owner
Copy Link

@ThomasLandauer commented on GitHub (Dec 8, 2022):

Sorry, I still had a 303-redirect in place yesterday...

So here we go - here's a reproducer: https://github.com/ThomasLandauer/doctrine-issue-10251

Just get the database going (see README.md), open public/index.php and click the "Save" button (don't change the name value).
=> You should see 504 queries in the Symfony web toolbar (500 of them are UPDATE)

Took me some time to reproduce, cause the issue only occurs if many requirements are met:

  • The entity needs to have an array of enums: 
    #[ORM\Column(type: Types::SIMPLE_ARRAY, nullable: true, enumType: Suit::class)]
    The updated 500 entities are the ones that actually do have a value in this column. (There are another 500 entities without a value.)
  • In the Controller, there needs to be an (unrelated) query for some entities ($mainRepository->findWhatever();)
  • This query needs to happen above the form handling (in the Controller)
  • And it needs to call a self-created method in the repository (i.e. not ->findAll() or similar)
@ThomasLandauer commented on GitHub (Dec 8, 2022): Sorry, I still had a 303-redirect in place yesterday... So here we go - here's a reproducer: https://github.com/ThomasLandauer/doctrine-issue-10251 Just get the database going (see README.md), open `public/index.php` and click the "Save" button (don't change the `name` value). => You should see 504 queries in the Symfony web toolbar (500 of them are `UPDATE`) Took me some time to reproduce, cause the issue only occurs if *many* requirements are met: * The entity needs to have an array of enums: ```php #[ORM\Column(type: Types::SIMPLE_ARRAY, nullable: true, enumType: Suit::class)] ``` The updated 500 entities are the ones that actually do have a value in this column. (There are another 500 entities without a value.) * In the Controller, there needs to be an (unrelated) query for some entities (`$mainRepository->findWhatever();`) * This query needs to happen **above** the form handling (in the Controller) * And it needs to call a self-created method in the repository (i.e. not `->findAll()` or similar)
admin commented 2026-01-22 15:44:11 +01:00
Author
Owner
Copy Link

@michnovka commented on GitHub (Dec 8, 2022):

aha, so this is an array of enums. ok, might explain the issues. I will look into this and let you know my findings, hopefully a fix also. thanks for the example

@michnovka commented on GitHub (Dec 8, 2022): aha, so this is an array of enums. ok, might explain the issues. I will look into this and let you know my findings, hopefully a fix also. thanks for the example
admin commented 2026-01-22 15:44:11 +01:00
Author
Owner
Copy Link

@ThomasLandauer commented on GitHub (Dec 8, 2022):

One more observation: I think (didn't verify) the 500 entities being updated are always a subset of the "unrelated" query in the controller.

@ThomasLandauer commented on GitHub (Dec 8, 2022): One more observation: I *think* (didn't verify) the 500 entities being updated are always a subset of the "unrelated" query in the controller.
admin commented 2026-01-22 15:44:12 +01:00
Author
Owner
Copy Link

@michnovka commented on GitHub (Dec 8, 2022):

I was able to isolate the issue and implement a fix - https://github.com/doctrine/orm/pull/10277

@michnovka commented on GitHub (Dec 8, 2022): I was able to isolate the issue and implement a fix - https://github.com/doctrine/orm/pull/10277
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7074
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?