DDC-555: @ManyToMany - curious behaviour - assigned values toggle #688

New Issue

admin · 2026-01-22T12:46:53+01:00

admin commented

2026-01-22 12:46:53 +01:00

Originally created by @doctrinebot on GitHub (Apr 29, 2010).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user jellobird:

BUG:
the entries in M:N table article_categories toggle

SOLUTION:
extra flush entry at [*]

Code:

$article = $em->find('Entity\Blog\Article', 1);

printf("-- %s\n", count($article->getCategories()));

$article->getCategories()->clear();
//$em->flush(); // [*]

foreach(array(4) as $id)$article->getCategories()->add(
            $em->getReference('Entity\Blog\Category', $id)
        );

$em->flush();

Entities:

class Article
{
/****
     * @ManyToMany(targetEntity="Entity\Blog\Category", inversedBy="articles")
     * @JoinTable(name="article_category",
     *             joinColumns={@JoinColumn(name="fk_article",  referencedColumnName="pk")},
     *      inverseJoinColumns={@JoinColumn(name="fk_category", referencedColumnName="pk")}
     * )
     */
    private $categories;
}

class Category
{
    /****
     * @ManyToMany(targetEntity="Entity\Blog\Article", mappedBy="categories")
     */
    private $articles;
}

tried to apply cascade={"all"}, but has no effect.

Originally created by @doctrinebot on GitHub (Apr 29, 2010). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user jellobird: BUG: the entries in M:N table article_categories toggle SOLUTION: extra flush entry at [*] ## Code: ``` $article = $em->find('Entity\Blog\Article', 1); printf("-- %s\n", count($article->getCategories())); $article->getCategories()->clear(); //$em->flush(); // [*] foreach(array(4) as $id)$article->getCategories()->add( $em->getReference('Entity\Blog\Category', $id) ); $em->flush(); ``` # Entities: ``` class Article { /**** * @ManyToMany(targetEntity="Entity\Blog\Category", inversedBy="articles") * @JoinTable(name="article_category", * joinColumns={@JoinColumn(name="fk_article", referencedColumnName="pk")}, * inverseJoinColumns={@JoinColumn(name="fk_category", referencedColumnName="pk")} * ) */ private $categories; } class Category { /**** * @ManyToMany(targetEntity="Entity\Blog\Article", mappedBy="categories") */ private $articles; } ``` tried to apply cascade={"all"}, but has no effect.

admin added the Bug label 2026-01-22 12:46:53 +01:00

admin closed this issue

2026-01-22 12:46:53 +01:00

admin commented

2026-01-22 12:46:54 +01:00

@doctrinebot commented on GitHub (Apr 29, 2010):

Comment created by @beberlei:

I dont understand this issue, can you please elaborate what exactly is wrong?

@doctrinebot commented on GitHub (Apr 29, 2010): Comment created by @beberlei: I dont understand this issue, can you please elaborate what exactly is wrong?

admin commented

2026-01-22 12:46:55 +01:00

@doctrinebot commented on GitHub (Apr 30, 2010):

Comment created by jellobird:

To be more verbose:

I have two tables article and category.
These tables are connected via a m:n-relationship with table article_category.

You can see the entity configuration snippets within the code Entities.

To reconstruct this bug, set up your database with these 3 tables. Put in some data, but keep the table article_category empty.

Now, with an properly configured entity manager, you can execute the displayed code.

There is a line {quote}printf("-- %s\n", count($article->getCategories()));{quote} which shows the number of categories connected with one article.

Please adjust array(4) to use valid category primary keys.

You will notice, as a result of this script, that sequential uses will produce

-- 0
-- n
-- 0
-- n
-- 0
...

with n the number of categories you add. it will be 1 in this example (see: array(4))

If you check the database between the runs, you will notice that the table article_categories is filled, empty, filled, empty, filled, ... corresponding to the script results.

SOLUTION: You can solve this with one extra line: $em->flush(); // [*]

I think the described behavior is not intended.

@doctrinebot commented on GitHub (Apr 30, 2010): Comment created by jellobird: To be more verbose: I have two tables article and category. These tables are connected via a m:n-relationship with table article_category. You can see the entity configuration snippets within the code Entities. To reconstruct this bug, set up your database with these 3 tables. Put in some data, but keep the table article_category empty. Now, with an properly configured entity manager, you can execute the displayed code. There is a line {quote}printf("-- %s\n", count($article->getCategories()));{quote} which shows the number of categories connected with one article. Please adjust array(4) to use valid category primary keys. You will notice, as a result of this script, that sequential uses will produce ``` -- 0 -- n -- 0 -- n -- 0 ... ``` with n the number of categories you add. it will be 1 in this example (see: array(4)) If you check the database between the runs, you will notice that the table article_categories is filled, empty, filled, empty, filled, ... corresponding to the script results. SOLUTION: You can solve this with one extra line: `$em->flush(); // [*]` I think the described behavior is not intended.

admin commented

2026-01-22 12:46:55 +01:00

@doctrinebot commented on GitHub (Jul 1, 2010):

Comment created by @beberlei:

The problem is that clear() is actually scheduling the deletion of the whole colleciton. This is a completly different operation compared to:

foreach ($col AS $obj) {
    $col->removeElement($obj);
}

If you do it this way and than re-add some of the objects, those associations will not be changed.

clear() however deletes all, then adds the new ones. again

@doctrinebot commented on GitHub (Jul 1, 2010): Comment created by @beberlei: The problem is that clear() is actually scheduling the deletion of the whole colleciton. This is a completly different operation compared to: ``` foreach ($col AS $obj) { $col->removeElement($obj); } ``` If you do it this way and than re-add some of the objects, those associations will not be changed. clear() however deletes all, then adds the new ones. again

admin commented

2026-01-22 12:46:56 +01:00

@doctrinebot commented on GitHub (Jul 3, 2010):

Comment created by @beberlei:

Verified as a bug though.

@doctrinebot commented on GitHub (Jul 3, 2010): Comment created by @beberlei: Verified as a bug though.

admin commented

2026-01-22 12:46:56 +01:00

@doctrinebot commented on GitHub (Jul 3, 2010):

Comment created by jellobird:

I see.

I suggest an additional method:

public function removeElements() { ... }

http://www.doctrine-project.org/jira/browse/DDC-665

@doctrinebot commented on GitHub (Jul 3, 2010): Comment created by jellobird: I see. I suggest an additional method: ``` public function removeElements() { ... } ``` http://www.doctrine-project.org/jira/browse/[DDC-665](http://www.doctrine-project.org/jira/browse/DDC-665)

admin commented

2026-01-22 12:46:57 +01:00

@doctrinebot commented on GitHub (Jul 3, 2010):

Comment created by @beberlei:

Not necessary, this was actually a bug. It should be fixed in the current master.

@doctrinebot commented on GitHub (Jul 3, 2010): Comment created by @beberlei: Not necessary, this was actually a bug. It should be fixed in the current master.

admin commented

2026-01-22 12:46:57 +01:00

@doctrinebot commented on GitHub (Jul 3, 2010):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Jul 3, 2010): Issue was closed with resolution "Fixed"

admin referenced this issue

2026-01-22 16:00:32 +01:00

[PR #688] [MERGED] Implement QuoteStrategy on SqlWalker walkRangeVariableDeclaration #8561

admin referenced this issue

2026-01-22 16:00:33 +01:00

[PR #688] Implement QuoteStrategy on SqlWalker walkRangeVariableDeclaration #8566

Sign in to join this conversation.