Closed jiripudil closed 8 months ago
Thank you for this report! Aren't there any other relationships? This seems quite similar to removing a book in our test suite (it has also a 1:1 to Ean and m:1 to other things) and it works. So I'd start with a reproduction.
Sure, I've pushed a minimal code to reproduce this to https://github.com/jiripudil/nextras-orm-bug-654
@jiripudil I've cherrypicked the fix to v4 branch, please test if it works for you. Thank you.
@hrach Works like a charm, thank you!
Hi, copying a bug report from Slack so that it can be tracked.
Relevant pieces of entities:
When I try to
$orm->remove($order)
where$order->delivery !== null
, orm throws NullValueException because it tries to set null to$order->mutation
. A debugging session led me intoRemovalHelper::getCascadeQueueAndSetNulls
and I am quite certain the culprit is there.The
getRelationships($order)
method call here returns:$pre
contains the order's 1:N relationships which then get removed in cascade. That's good.$nulls
contains the order's N:1 relationships, including$mutation
. This is not an issue by itself but is's a prerequisite to the problem.$post
contains 1:1 relationships, including$delivery
. The helper callsgetCascadeQueueAndSetNulls()
upon them recursively, and thesetNulls
call somehow enqueues the relationship's reverse side (i.e. the order) into$queuePersist
, even though it's in$queueRemove
from the very beginning. Combined with the previous bullet point, it raises the NullValueException because prior to removing things, orm tries to persist the null values in$order
.Since #235, Orm seems to handle this situation for the owning side but not for the reverse side (which is our case). I'm not sure why or what the consequences of introducing it would be.
(Yep, it would likely help to switch the sides of the relationship, but I feel that it should not matter. I want to remove the whole thing anyway.)
orm 4.0.7, dbal 4.0.5