[DDC-2074] Bugfix regarding clearing cloned PersistentCollections #523

Merged
merged 2 commits into from Nov 25, 2012

Conversation

Projects
None yet
3 participants
@jankramer
Contributor

jankramer commented Nov 25, 2012

When calling clear on a PC that has no owner (e.g. because it was cloned), it can't be deleted as there is no metadata available (that's essentially the exception mentioned in the ticket). In these cases, I think it shouldn't be scheduled for deletion, but please have a look as my knowledge of the ORM internals is limited.

jankramer added some commits Nov 25, 2012

[DDC-2074] Fixed bug regarding clearing PC's without owner
When calling clear on a PC that has no owner (e.g. because it was
cloned), it can't be deleted as there is no metadata available.
In these cases, it shouldn't be scheduled for deletion.
@doctrinebot

This comment has been minimized.

Show comment Hide comment
@doctrinebot

doctrinebot Nov 25, 2012

Hello,

thank you for positing this Pull Request. I have automatically opened an issue on our Jira Bug Tracker for you with the details of this Pull-Request. See the Link:

http://doctrine-project.org/jira/browse/DDC-2168

Hello,

thank you for positing this Pull Request. I have automatically opened an issue on our Jira Bug Tracker for you with the details of this Pull-Request. See the Link:

http://doctrine-project.org/jira/browse/DDC-2168

beberlei added a commit that referenced this pull request Nov 25, 2012

Merge pull request #523 from jankramer/DDC-2074
[DDC-2074] Bugfix regarding clearing cloned PersistentCollections

@beberlei beberlei merged commit 46e6753 into doctrine:master Nov 25, 2012

1 check passed

default The Travis build passed
Details
@beberlei

This comment has been minimized.

Show comment Hide comment
@beberlei

beberlei Nov 25, 2012

Member

@jankramer DDC-2074 is about something completly different. What ticket did you mean?

Member

beberlei commented Nov 25, 2012

@jankramer DDC-2074 is about something completly different. What ticket did you mean?

@jankramer

This comment has been minimized.

Show comment Hide comment
@jankramer

jankramer Nov 25, 2012

Contributor

Oh sorry, I forgot to explain this a little more. I now see that the ticket seems unrelated. However, this fix does solve the root cause of the exception Steffan mentions.

What happens is that in the Symfony form component, the PC is cleared. Because the PC is in fact a cloned instance, the owner is null. This causes get_class in the ManyToManyPersister to return "ManyToManyPersister", of which it can obviously find no ClassMetadata.

In any case, this solves the mentioned ticket, but I think the error handling in the ManyToManyPersister could be a bit more helpful as well. For example by checking whether the owner on the collection is set.

Contributor

jankramer commented Nov 25, 2012

Oh sorry, I forgot to explain this a little more. I now see that the ticket seems unrelated. However, this fix does solve the root cause of the exception Steffan mentions.

What happens is that in the Symfony form component, the PC is cleared. Because the PC is in fact a cloned instance, the owner is null. This causes get_class in the ManyToManyPersister to return "ManyToManyPersister", of which it can obviously find no ClassMetadata.

In any case, this solves the mentioned ticket, but I think the error handling in the ManyToManyPersister could be a bit more helpful as well. For example by checking whether the owner on the collection is set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment