Cascade remove/set null behavior

[hrach]

Currently, there three options for has many relationships (eg. Author has many Books)

1. do not set nothing and the other side is nullable: removing the author make the book author-less.
2. do not set nothing and the other side is not nullable: an exception is thrown;
3. set cascade remove, the book is removed too;

I see a room for improvement. The main point it is quite easy to forget a cascade behavior, thought, bind a cascade behavior to the nullability is not so much correct.
→
The default behavior could be to throw an exception if a dependency is wired (e.g. something is in relationship), possible cascade values could be (the current) remove and (the new one) setNullOnRemove.

---

Also, I'm thinking about solution to the huge relationship, when it may be convenient to do the cascade in storage layer, then something like removeIgnore would be great and refreshAll()/new identity map would reload the correct db state.

[hrach]

E.g. the issue here is that when there is a nullable relationship, the default remove call do a set null without any notice. Not a big issue, but may be rethought as described.

[mskocik]

I came across this one. Maybe I just don't understand it correctly. I would expect, that following code should work:

// returns 3 items
$existingTags = $target->tags->toCollection()->fetchAll();
// want to keep only 2 of them
$toKeep = [$existingTags[0], $existingTags[2]]; 

$target->tags->set($toKeep);
$targetRepository->persist($target);

But NullValueException is thrown that Property Tag::$target is not nullable.
I was able to make it behave as expected with this code:

// returns 3 items
$existingTags = $target->tags->toCollection()->fetchAll();
$tagRepo->remove($existingTags[1]);// 👈 this has been added
// want to keep only 2 of them
$toKeep = [$existingTags[0], $existingTags[2]]; 

$target->tags->set($toKeep);
$targetRepository->persist($target);
// add to line 3

So my question is. Should the first code example work? Or the line with $tagRepo is required?

[hrach]

@mskocik It seems your usecase is rather #205. Anyway, the second example is overcomplicated, the relationships are synced, i.e. calling remove is sufficient. No need to set() & persist on the other side.