-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DDC-3343] Entities should not be deleted when using EXTRA_LAZY and one-to-many #1169
Conversation
$this->_em->clear(); | ||
|
||
$user = $this->_em->find(__NAMESPACE__ . '\DDC3343User', $user->id); | ||
$this->assertNotNull($user); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use assertInstanceOf
here
I've experienced this issue as well. Entity mapped with Extra Lazy loading. I want to remove element from a collection on the "One" side of the ManyToOne relationship, but not delete the entity from the database. This issues a delete query to delete the record of entity being removed from the collection when it should actually not issue a query at all (or just null out of the foreign key column). |
@Ocramius any updates? do you want me to propose a fix? |
@asprega I didn't check this yet |
…ociated values when they are removed, but just update the owning side
…azy specific tests (some DELETE operations became UPDATE operations)
… an extra-lazy collection still updates the owning side values
Moved to #1281 |
… a delete operation down to the DB
… a delete operation down to the DB
…-many-is-noop-when-not-doing-orphan-removal Hotfix - #1169 - extra lazy one to many must be no-op when not doing orphan removal
…anges should be no-op unless orphan removal is specified.
…anges should be no-op unless orphan removal is specified.
…y + one-to-many element removal behavior
…(failing tests)
…existing properties, inexisting owning side assigned
…ith the data when `orphanRemoval` and `EXTRA_LAZY` are combined
…anges should be no-op unless orphan removal is specified.
…anges should be no-op unless orphan removal is specified.
…y + one-to-many element removal behavior
… (failing tests)
…nexisting properties, inexisting owning side assigned
…with the data when `orphanRemoval` and `EXTRA_LAZY` are combined
…picking conflicts
…hey are orphaned and EXTRA_LAZY is used
…tity persister to perform deletes on the owning side
…c (sorting deletes by FK dependencies)
…any-persister-deletes-only-on-extra-lazy-plus-orphan-removal-2.4 [2.4] #1169 DDC-3343 one-to-omany persister deletes only on EXTRA_LAZY plus orphanRemoval
Here's a failing test case for the issue I filed a few days ago: http://www.doctrine-project.org/jira/browse/DDC-3343
Notifying @Ocramius.