DDC-108: Transitive persistence broken #135

Closed
opened 2026-01-22 12:28:14 +01:00 by admin · 3 comments
Owner

Originally created by @doctrinebot on GitHub (Nov 3, 2009).

Jira issue originally created by user nicokaiser:

When cascading 'persist' operations, the object which was not persisted implicitly is being written to the DB with wrong parameters, broken SQL:

INSERT INTO email (email, userId) VALUES (?, ?) array(3) { [1]=> NULL [2]=> string(16) "user@example.com" [3]=> int(1) }

See the attached example for details... When I uncomment the "$em->persist($email);" line, everything works as expected (but I'd like this persist to be done automatically...)

Originally created by @doctrinebot on GitHub (Nov 3, 2009). Jira issue originally created by user nicokaiser: When cascading 'persist' operations, the object which was not persisted implicitly is being written to the DB with wrong parameters, broken SQL: `INSERT INTO email (email, userId) VALUES (?, ?) array(3) { [1]=> NULL [2]=> string(16) "user@example.com" [3]=> int(1) }` See the attached example for details... When I uncomment the "$em->persist($email);" line, everything works as expected (but I'd like this persist to be done automatically...)
admin added the Bug label 2026-01-22 12:28:14 +01:00
admin closed this issue 2026-01-22 12:28:15 +01:00
Author
Owner

@doctrinebot commented on GitHub (Nov 3, 2009):

Comment created by romanb:

Indeed this looks like a bug, but it is unrelated to cascades.

I will explain on your code sample:

$em = EntityManager::create($connectionOptions, $config);
$user = new \Entity\User;
$user->setName('Bob');

// This would invoke persist() on the associated email because of the cascade, but there is no email yet!
// After persist() $user is MANAGED
$em->persist($user);

$email = new \Entity\Email;
$email->setEmail('user@example.com');
$user->addEmails($email);

// On flush the email should be correctly persisted because it is NEW but referenced/reachable from a MANAGED entity ($user)
$em->flush();

Just to clarify. So this is a bug in the "persistence by reachability".

"persistence by reachability" means that a NEW entity (like $email) that is associated to a MANAGED entity (like $user) and the association has cascade=persist is automatically persisted on flush().

I still need to write about persistence by reachability in the manual but as you have already found out, it is intuitive since you expect that to happen.

@doctrinebot commented on GitHub (Nov 3, 2009): Comment created by romanb: Indeed this looks like a bug, but it is unrelated to cascades. I will explain on your code sample: ``` $em = EntityManager::create($connectionOptions, $config); $user = new \Entity\User; $user->setName('Bob'); // This would invoke persist() on the associated email because of the cascade, but there is no email yet! // After persist() $user is MANAGED $em->persist($user); $email = new \Entity\Email; $email->setEmail('user@example.com'); $user->addEmails($email); // On flush the email should be correctly persisted because it is NEW but referenced/reachable from a MANAGED entity ($user) $em->flush(); ``` Just to clarify. So this is a bug in the "persistence by reachability". "persistence by reachability" means that a NEW entity (like $email) that is associated to a MANAGED entity (like $user) and the association has cascade=persist is automatically persisted on flush(). I still need to write about persistence by reachability in the manual but as you have already found out, it is intuitive since you expect that to happen.
Author
Owner

@doctrinebot commented on GitHub (Nov 3, 2009):

Comment created by romanb:

Ok its not completely unrelated to cascades since persistence by reachability still requires cascade=persist ;) but the bug itself has to do with incorrect changeset calculation.

@doctrinebot commented on GitHub (Nov 3, 2009): Comment created by romanb: Ok its not **completely** unrelated to cascades since persistence by reachability still requires cascade=persist ;) but the bug itself has to do with incorrect changeset calculation.
Author
Owner

@doctrinebot commented on GitHub (Nov 3, 2009):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Nov 3, 2009): Issue was closed with resolution "Fixed"
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#135