Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2703

UnitOfWork should not compute the change set on updated but not-persisted entities.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: Git Master
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None
    • Environment:
      PHP 5.3 with SQLite 3 and PHP 5.4 with MySQL 5.5

      Description

      Problem:
      UnitOfWork computes the change set on updated but not-persisted entities.

      How to reproduce:

      1. Suppose I have 2 entities of class Node stored on the database of choices.
      2. Load the entities via the respective repository (to ensure that the unit of work manages them).
      3. Update something on both entities.
      4. Only store one of them.

      Expectation:

      Any changes on the entity which is not persisted must not be stored in the database.

      Actual Result:

      The changes are saved.

      Use the example:

      1. Clone the demo app from git@github.com:shiroyuki/trphp13-demo.git.
      2. Run the preparation commands to create the database (one DB called "trphp13"), schema (one table called "product") and load fixtures (3 entities).
      3. Run app/console sandbox:case0 to recreate the bug.

      Note:

      I traced the bug down to computeChangeSet and it seems that even though the entity is not scheduled for dirty checks, the unit of work still computes the change set of the problematic entity. From the provided example, the node named "Node 2" should not be updated to "B" when the CaseZero command is executed.

        Activity

        Hide
        Marco Pivetta added a comment -

        Juti Noppornpitak we are not going to checkout your project for this. Please make a small example that uses ONLY the ORM, with no other involved frameworks.

        You should be able to do that in a single php script that includes:

        1) the involved entities
        2) an initialization of the ORM
        3) the functional example

        we can then convert that into a unit test once it has been verified.

        Show
        Marco Pivetta added a comment - Juti Noppornpitak we are not going to checkout your project for this. Please make a small example that uses ONLY the ORM, with no other involved frameworks. You should be able to do that in a single php script that includes: 1) the involved entities 2) an initialization of the ORM 3) the functional example we can then convert that into a unit test once it has been verified.
        Hide
        Guilherme Blanco added a comment - - edited

        This should be related to change tracking policy.
        Doctrine uses IMPLICIT change tracking policy by default, applying an algorithm called persist-by-reachability.
        To fix your issue, you need to modify your change tracking to DEFERRED_EXPLICIT or NOTIFY.

        Here is a more detailed explanation:

        So the change you need to do is: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/change-tracking-policies.html

        /**
         * @ORM\Entity
         * @ORM\ChangeTrackingPolicy("DEFERRED_EXPLICIT")
         */
        class Node
        {
            // ...
        }
        
        Show
        Guilherme Blanco added a comment - - edited This should be related to change tracking policy. Doctrine uses IMPLICIT change tracking policy by default, applying an algorithm called persist-by-reachability. To fix your issue, you need to modify your change tracking to DEFERRED_EXPLICIT or NOTIFY. Here is a more detailed explanation: So the change you need to do is: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/change-tracking-policies.html /** * @ORM\Entity * @ORM\ChangeTrackingPolicy( "DEFERRED_EXPLICIT" ) */ class Node { // ... }
        Hide
        Guilherme Blanco added a comment -

        It's an issue of misunderstanding change tracking policies.

        Show
        Guilherme Blanco added a comment - It's an issue of misunderstanding change tracking policies.
        Hide
        Juti Noppornpitak added a comment -

        Thank you.

        Show
        Juti Noppornpitak added a comment - Thank you.

          People

          • Assignee:
            Guilherme Blanco
            Reporter:
            Juti Noppornpitak
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: