Doctrine 2 - ORM

@ManyToMany - curious behaviour - assigned values toggle

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.0-ALPHA4
  • Fix Version/s: 2.0-BETA3
  • Component/s: ORM
  • Security Level: All
  • Labels:
    None
  • Environment:

Description

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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Eberlei added a comment -

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

Show
Benjamin Eberlei added a comment - I dont understand this issue, can you please elaborate what exactly is wrong?
Hide
Permalink
Romeo Disca added a comment -

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

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

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.

Show
Romeo Disca added a comment - 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 printf("-- %s\n", count($article->getCategories())); 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.
Hide
Permalink
Benjamin Eberlei added a comment -

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

Show
Benjamin Eberlei added a comment - 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
Hide
Permalink
Benjamin Eberlei added a comment -

Verified as a bug though.

Show
Benjamin Eberlei added a comment - Verified as a bug though.
Hide
Permalink
Romeo Disca added a comment -

I see.

I suggest an additional method:

public function removeElements() { ... }

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

Show
Romeo Disca added a comment - I see. I suggest an additional method: public function removeElements() { ... } http://www.doctrine-project.org/jira/browse/DDC-665
Hide
Permalink
Benjamin Eberlei added a comment -

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

Show
Benjamin Eberlei added a comment - Not necessary, this was actually a bug. It should be fixed in the current master.

People

  • Assignee:
    Benjamin Eberlei
    Reporter:
    Romeo Disca
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: