Skip to content


Possible bug in object relation code? #603

marcj opened this Issue · 4 comments

2 participants

Propel member

I've created a testcase that should prove the bahaviour.

TestSuite output:

$ phpunit test/testsuite/misc/MoreRelationTest.php
PHPUnit 3.7.13 by Sebastian Bergmann.

Configuration read from /Users/marc/Propel/phpunit.xml.dist


Time: 0 seconds, Memory: 18.75Mb

There was 1 failure:

1) MoreRelationTest::testContentsDeletion
We assigned a collection of only one item.
Failed asserting that 4 matches expected 1.


Tests: 1, Assertions: 2, Failures: 1.

Is this a desired behaviour? If I apply the following patch, then the testcase is OK.

diff --git a/generator/lib/builder/om/PHP5ObjectBuilder.php b/generator/lib/builder/om/PHP5ObjectBuilder.php
index 1fba18f..ad3c6b6 100644
--- a/generator/lib/builder/om/PHP5ObjectBuilder.php
+++ b/generator/lib/builder/om/PHP5ObjectBuilder.php
@@ -3824,7 +3824,7 @@ abstract class ".$this->getClassname()." extends ".$parentClass." ";
         \${$inputCollection}ToDelete = \$this->get{$relatedName}(new Criteria(), \$con)->diff(\${$inputCollection});

-        \$this->{$inputCollection}ScheduledForDeletion = unserialize(serialize(\${$inputCollection}ToDelete));
+        \$this->{$inputCollection}ScheduledForDeletion = \${$inputCollection}ToDelete;

         foreach (\${$inputCollection}ToDelete as \${$inputCollectionEntry}Removed) {

I believe through this unserialize(serialize( call the next call Removed->set{$relCol}(null); doesn't have any effect, does it?

Propel member

Here's the commit, that brought in this unserialize(serialize( call:

Propel member

After applying the patch above, which removes the unserialize(serialize( call, one assertions fails:

1) GeneratedObjectTest::testReplace_RelationWithCompositePK
Only 1 BookOpinion; the new one got inserted and the previously associated one got deleted
Failed asserting that 2 matches expected 1.


This test is also brought in by the same commit that brought in the unserialize(serialize( call. So either my test case is based on a false assumption or the test case of b489a97.

Propel member

Ok, these two test cases differs. Mine has only one PK and the other has a composite PK. Between this two ways of having a PK the save method of the collection ScheduledForDeletion differs, too. So the idea behind the patch of b489a97 is that he 'unlinks' the ScheduledForDeletion collection so the set<RelationName>(null) does not affect ScheduledForDeletion, so the bookOpinionsScheduledForDeletion->getPrimaryKeys later has the correct PK values. Mh, lemme see if I can fix this, because this behaviour is only needed for composite PKs.

Propel member

more exact: this behaviour of unlinking the ScheduledForDeletion array is only needed for PKs that are at the same times FKs. If we set the FK to NULL we also set then the PK to null and have therefore no possibility to delete the item later. So $fk->isLocalPrimaryKey() instead of isComposite() is more sensible here, and then make a backup of the PK values through unserialize(serialize( if it returns true.

@marcj marcj added a commit to marcj/Propel that referenced this issue
@marcj marcj Fixed #603.
Added a test set that proves the bug.
@marcj marcj referenced this issue

Fix #603 #604

@marcj marcj added a commit to marcj/Propel that referenced this issue
@marcj marcj Fixed #603 bb9ae3d
@willdurand willdurand pushed a commit that closed this issue
@marcj marcj Fixed #603 288e91d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.