Allow overriding association's cascade #11549
Conversation
| @@ -870,13 +870,23 @@ public function testAssociationOverrideKeepsDeclaringClass(): void | |||
| { | |||
| $cm = new ClassMetadata(Directory::class); | |||
| $cm->mapManyToOne(['fieldName' => 'parentDirectory', 'targetEntity' => Directory::class, 'cascade' => ['remove'], 'declared' => Directory::class]); | |||
| $cm->setAssociationOverride('parentDirectory', ['cascade' => '']); | |||
| $cm->setAssociationOverride('parentDirectory', ['cascade' => ['remove']]); | |||
There was a problem hiding this comment.
Why this change in the test?
There was a problem hiding this comment.
Previously cascade was ignored, now it's leading to an error as it's supposed to be an array of strings. I reckon this test was originally done to pass something and see if nothing (declaring class) breaks
I gave it some thought and couldn't think of any reason this would be omitted on purpose. My guess is that nobody needed it as overriding association is not very common: people either configure things themselves or roll with vendors. I don't like vendors shooting me in the foot :D |
|
There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days. |
|
@SenseException can we treat this as bugfix and still merge to 3.x? |
|
I guess being the only option that can't be overridden could be interpreted as a bug. I guess this is a situation that can be argued about. 😁 I would give an okay to handle this as a bugfix. |
We were badly bitten by
cascadeset on an association we did not expect it to have. The association is dynamically mapped using aloadClassMetadataevent by a vendor with no way of hooking into it. As we're really careful with persisting stuff I'd like to have an option to remove vendor's cascade and instead take care of it within our codebase.Additionally I've listed what can actually be overridden as I was surprised it's that limited :)