Doctrine refresh occurring without refresh added to cascade options #5252

New Issue

admin · 2026-01-22T15:02:42+01:00

admin commented

2026-01-22 15:02:42 +01:00

Originally created by @djones8520 on GitHub (Sep 13, 2016).

Doctrine version- 2.5.5-DEV

I'm having a problem with doctrine refresh, refreshing associations even if refresh is not in the cascade options. Below is part of a ymal mapping for an ItemNode entity.

oneToOne:
orderItem:
  targetEntity: OS\Domain\Entity\Order\OrderItem
  mappedBy: itemNode
zoneHistory:
  targetEntity: OS\Domain\Entity\Zone\ZoneHistory
  mappedBy: itemNode
  cascade: ['persist']

A refresh on an ItemNode object will refresh its data, however, data on its zoneHistory is also being refreshed. For example, ZoneHistory has a status field that was changed earlier, but after the refresh, the status is reverted.

The interesting part, is that any change on the OrderItem is not refreshed unless refresh is added to the cascade.

oneToOne:
orderItem:
  targetEntity: OS\Domain\Entity\Order\OrderItem
  mappedBy: itemNode
  cascade: ['refresh']

Thanks for any suggestions.

Originally created by @djones8520 on GitHub (Sep 13, 2016). Doctrine version- 2.5.5-DEV I'm having a problem with doctrine refresh, refreshing associations even if refresh is not in the cascade options. Below is part of a ymal mapping for an ItemNode entity. ``` oneToOne: orderItem: targetEntity: OS\Domain\Entity\Order\OrderItem mappedBy: itemNode zoneHistory: targetEntity: OS\Domain\Entity\Zone\ZoneHistory mappedBy: itemNode cascade: ['persist'] ``` A refresh on an ItemNode object will refresh its data, however, data on its zoneHistory is also being refreshed. For example, ZoneHistory has a status field that was changed earlier, but after the refresh, the status is reverted. The interesting part, is that any change on the OrderItem is not refreshed unless refresh is added to the cascade. ``` oneToOne: orderItem: targetEntity: OS\Domain\Entity\Order\OrderItem mappedBy: itemNode cascade: ['refresh'] ``` Thanks for any suggestions.

admin commented

2026-01-22 15:02:43 +01:00

@fromthecove commented on GitHub (Nov 19, 2018):

I know this is an old issue, but I just ran into something very similar: refresh was cascading to an entity for which I had no cascade refresh configured. After stepping through the code, I discovered when the BasicEntityPersister::refresh method builds its SQL query for the refresh, it takes the FETCH configuration for the associations into account.

By any chance, do you have the fetch mode configured to EAGER anywhere? Perhaps your ItemNode -> zoneHistory fetch? If it is, then when you call refresh on ItemNode, and Doctrine builds the query to reload the data from the database, it will also JOIN in the data for the related zoneHistory because you have it set to eager fetch.

That was my issue. Personally, I think when doing a refresh Doctrine should ignore any configured fetch mode.

@fromthecove commented on GitHub (Nov 19, 2018): I know this is an old issue, but I just ran into something very similar: refresh was cascading to an entity for which I had no cascade refresh configured. After stepping through the code, I discovered when the BasicEntityPersister::refresh method builds its SQL query for the refresh, it takes the FETCH configuration for the associations into account. By any chance, do you have the fetch mode configured to EAGER anywhere? Perhaps your ItemNode -> zoneHistory fetch? If it is, then when you call refresh on ItemNode, and Doctrine builds the query to reload the data from the database, it will also JOIN in the data for the related zoneHistory because you have it set to eager fetch. That was my issue. Personally, I think when doing a refresh Doctrine should ignore any configured fetch mode.

admin commented

2026-01-22 15:02:44 +01:00

@djones8520 commented on GitHub (Dec 4, 2018):

The fetch mode is lazy by default right? If I have it set, it's always lazy. I don't recall ever setting a different fetch mode. I do sort of remember working on something with fetch, but it's been so long that I don't remember what I did. I probably ended up working around it.

@djones8520 commented on GitHub (Dec 4, 2018): The fetch mode is lazy by default right? If I have it set, it's always lazy. I don't recall ever setting a different fetch mode. I do sort of remember working on something with fetch, but it's been so long that I don't remember what I did. I probably ended up working around it.

admin commented

2026-01-22 15:02:44 +01:00

@Erdou commented on GitHub (Feb 2, 2021):

Thank you @dlowhorn !
I had a very similar issue: very long or unterminating PHP processes. It was because of em->refresh() coupled with some cyclic fetch=EAGER. Just reviewed all fetch=EAGER columns to remove any cycle (while trying to keep the "best" ones in terms of performance), and I don't have anymore issues.

But that said I don't think it would ignore it as fetch=EAGER's goal is to auto-join for performances, IMHO it should detect cycles to stop at the first encountered one.

@Erdou commented on GitHub (Feb 2, 2021): Thank you @dlowhorn ! I had a very similar issue: very long or unterminating PHP processes. It was because of `em->refresh()` coupled with some cyclic `fetch=EAGER`. Just reviewed all `fetch=EAGER` columns to remove any cycle (while trying to keep the "best" ones in terms of performance), and I don't have anymore issues. But that said I don't think it would ignore it as `fetch=EAGER`'s goal is to auto-join for performances, IMHO it should detect cycles to stop at the first encountered one.

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