Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2332

[UnitOfWork::doPersist()] The spl_objact_hash() generate not unique hash!

    Details

    • Type: Bug Bug
    • Status: Awaiting Feedback
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None
    • Environment:
      Symfony 2.1.8, php 5.4.7 and php 5.4.12, Windows 7

      Description

      I created fixtures and some data was inserted many times without calling the Task entity PrePersist event listener.

      I printed the used and generated hash and I saw a Proxies_CG_\Asitly\ProjectManagementBundle\Entity\User hash equal a Task entity hash!

      1. hashlogs.txt
        324 kB
        Krisztián Ferenczi

        Activity

        Krisztián Ferenczi created issue -
        Hide
        Marco Pivetta added a comment -

        Please provide either a code example or a test case. As it stands, this issue is incomplete

        Show
        Marco Pivetta added a comment - Please provide either a code example or a test case. As it stands, this issue is incomplete
        Marco Pivetta made changes -
        Field Original Value New Value
        Security All [ 10000 ]
        Hide
        Benjamin Eberlei added a comment -

        Are you calling EntityManager#clear() inbetween? Because PHP reuses the hashes. The ORM accounts for this.

        Show
        Benjamin Eberlei added a comment - Are you calling EntityManager#clear() inbetween? Because PHP reuses the hashes. The ORM accounts for this.
        Krisztián Ferenczi made changes -
        Environment Symfony 2.1.8, php 5.4.7 Symfony 2.1.8, php 5.4.7 and php 5.4.12, Windows 7
        Hide
        Benjamin Eberlei added a comment -

        This is not a reproduce case, i don't want to execute your whole project.

        I want to know, what is the actual bug that you see? Can you just print a list of all the hashes? Because the hashes dont differ at the end, bu tjust somewhere in the middle.

        Show
        Benjamin Eberlei added a comment - This is not a reproduce case, i don't want to execute your whole project. I want to know, what is the actual bug that you see? Can you just print a list of all the hashes? Because the hashes dont differ at the end, bu tjust somewhere in the middle.
        Krisztián Ferenczi made changes -
        Comment [ Oh, sorry, the important files:
        - src\...\EventListener\UuidListener.php
        - UnitOfWork.php
        - src\...\DataFixtures\ORM\LoadTaskData.php ]
        Hide
        Krisztián Ferenczi added a comment - - edited

        I attached a hashlogs.txt file. The last Task class hash is 0000000050ab4aba0000000058e1cb12 ( line 3 129 )

        This is not unique, view the line 2 760 . The Task is not being saved and the program don't call the prePersist listener. The "UnitOfWork" believe the entity has been saved because the isset($this->entityStates[$oid]) is true. But it is an other entity.

        Show
        Krisztián Ferenczi added a comment - - edited I attached a hashlogs.txt file. The last Task class hash is 0000000050ab4aba0000000058e1cb12 ( line 3 129 ) This is not unique, view the line 2 760 . The Task is not being saved and the program don't call the prePersist listener. The "UnitOfWork" believe the entity has been saved because the isset($this->entityStates [$oid] ) is true. But it is an other entity.
        Krisztián Ferenczi made changes -
        Attachment hashlogs.txt [ 11510 ]
        Hide
        Krisztián Ferenczi added a comment -

        The EntityManager::clear() fix the problem, but this is not "good" and "beautiful" solution. Shows no sign of that conflicts were and this is causing the problem. I was looking for the problem 7 hours.

        Show
        Krisztián Ferenczi added a comment - The EntityManager::clear() fix the problem, but this is not "good" and "beautiful" solution. Shows no sign of that conflicts were and this is causing the problem. I was looking for the problem 7 hours.
        Benjamin Eberlei made changes -
        Priority Major [ 3 ] Critical [ 2 ]
        Mauricio Leonardo Rivera Torres made changes -
        Status Open [ 1 ] Awaiting Feedback [ 10000 ]
        Hide
        Marco Pivetta added a comment -

        One possible issue here is that a listener registers an entity as managed while a proxy is being loaded.

        The given data is still insufficient to actually verify the problem.

        Show
        Marco Pivetta added a comment - One possible issue here is that a listener registers an entity as managed while a proxy is being loaded. The given data is still insufficient to actually verify the problem.
        Marco Pivetta made changes -
        Priority Critical [ 2 ] Major [ 3 ]

        This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

        • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-2332, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Krisztián Ferenczi
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: