Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-555

@ManyToMany - curious behaviour - assigned values toggle

    Details

    • Type: Bug Bug
    • Status: 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

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

        Verified as a bug though.

        Show
        Benjamin Eberlei added a comment - Verified as a bug though.
        Hide
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: