Jira issue originally created by user sbeining:
If the cascade option for an association includes the "refresh" keyword, the associated entites are only refreshed, if the collection is not lazy loaded.
The problem is that first the "parent" entity is reloaded, so the associations PersistentCollection is replaced with a new one that has not been initialized yet. And then in cascadeRefresh, the code explicitly avoids initializing that collection, so there will never be any entities in the wrapped ArrayCollection that the operation may cascade to.
I can see at least two possible solutions for this problem. One would be to swap the order of the operations, so that the cascading happens first. This would cascade based on the current object model state (pre-refresh), so entities that had been detached would not be refreshed.
The other would be to remember which collections had already been loaded, and to initialize the corresponding new collections before performing the cascading. That would cascade based on the refreshed state, so in this case, entities that had been newly attached would not be refreshed.
My current use-case would work with the first one, but I guess there will be some use-cases that would require the second one... :-/
Comment created by @beberlei:
Tricky issue. I share your analysis and ask myself if there is really a use-case for 2. If you ask for a refresh of the current state, that obviously means the current associations. Hence cascading first would be the solution here.
The problem is that the entities are still in memory and a consecutive access of the "new" collection returns them in their non-refreshed state.
You could help with solving this issue, can you create a TestCase like the ones in tests/Doctrine/Tests/ORM/Functional/Ticket/* and attach it here? It would be best against master, but ok if you do it against 2.1.7.
Comment created by @ocramius:
[~sbeining] 2.1 is not supported anymore. Can you verify if this behaviour is still reproducible in 2.3?
Comment created by @asm89:
closing in favor of DDC-2143
Issue was closed with resolution "Invalid"
Comment created by MartijnD:
I'm experiencing the same issue in 2.4.6. Should I create a new issue for this?
This issue was resolved as invalid: please design a test case before opening a new issue.