DDC-1662: oprhanRemoval=true vs casdade={remove} for OneToMany relationships #2088

Closed
opened 2026-01-22 13:40:16 +01:00 by admin · 3 comments
Owner

Originally created by @doctrinebot on GitHub (Feb 21, 2012).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user juokaz:

Client has a data structure like PhoneBook->Address[]. PhoneBook has many addresses.

They have expectations as:

Removing address from collection removes the address entity

Deleting phonebook checks if there are addresses and if there are constrain should fail

In code:

<?php

$phoneBook = new PhoneBook();
$phoneBook->addAddress(new Address()); 

$em->persist($phoneBook); // phonebook has cascade = {persist}
$em->flush();

first case

<?php
$pb->getAddresses()->removeElement($address);
$em->flush();

second case

$em->remove($pb);
$em->flush();

Adding orphanRemoval = true, makes first case work, but also implicitly defines cascade={remove} for second case, as all addresses are then removed on phonebook remove.

It looks to me like a feature (or design idea) rather than a bug. Any comments?

Originally created by @doctrinebot on GitHub (Feb 21, 2012). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user juokaz: Client has a data structure like PhoneBook->Address[]. PhoneBook has many addresses. They have expectations as: # Removing address from collection removes the address entity # Deleting phonebook checks if there are addresses and if there are constrain should fail In code: ``` php <?php $phoneBook = new PhoneBook(); $phoneBook->addAddress(new Address()); $em->persist($phoneBook); // phonebook has cascade = {persist} $em->flush(); ``` first case ``` php <?php $pb->getAddresses()->removeElement($address); $em->flush(); ``` second case ``` php $em->remove($pb); $em->flush(); ``` Adding orphanRemoval = true, makes first case work, but also implicitly defines cascade={remove} for second case, as all addresses are then removed on phonebook remove. It looks to me like a feature (or design idea) rather than a bug. Any comments?
admin added the Bug label 2026-01-22 13:40:16 +01:00
admin closed this issue 2026-01-22 13:40:18 +01:00
Author
Owner

@doctrinebot commented on GitHub (Feb 21, 2012):

Comment created by @beberlei:

The second case is domain logic, not something that doctrine/database should enforce. You can add a preRemove check to fail if a phonebook contains addresses.

@doctrinebot commented on GitHub (Feb 21, 2012): Comment created by @beberlei: The second case is domain logic, not something that doctrine/database should enforce. You can add a preRemove check to fail if a phonebook contains addresses.
Author
Owner

@doctrinebot commented on GitHub (Feb 21, 2012):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Feb 21, 2012): Issue was closed with resolution "Invalid"
Author
Owner

@doctrinebot commented on GitHub (Feb 21, 2012):

Comment created by @beberlei:

That means yes, orphanRemoval=true should be set here, and the second case should be checked in the domain of the project.

@doctrinebot commented on GitHub (Feb 21, 2012): Comment created by @beberlei: That means yes, orphanRemoval=true should be set here, and the second case should be checked in the domain of the project.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#2088