The original optimization was buggy and got reverted in #798.
The culprit was that the "current" side not being loaded is not enough to be sure we don't have to null it as the other side may be loaded.
The complexity arises from the fact that we do not know how to get to the other side when our side is unloaded.
The nulling skip should be possible only in the case that the database has a correct constraint to set to null on removal - but that's somehow an implicit expectation, but I guess we should better document the relationship between cascade in Orm & foreign key ON DELETE expectations.
The original optimization was buggy and got reverted in #798.
The culprit was that the "current" side not being loaded is not enough to be sure we don't have to null it as the other side may be loaded.
The complexity arises from the fact that we do not know how to get to the other side when our side is unloaded.
The nulling skip should be possible only in the case that the database has a correct constraint to set to null on removal - but that's somehow an implicit expectation, but I guess we should better document the relationship between cascade in Orm & foreign key ON DELETE expectations.