Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Git Master
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      When doing `persist()` and then `flush()` the statements are not accessible anymore after the operation is done.

      The EntityManager uses an EntityPersister. When looking at the BasicEntityPersister->executeInserts() a new statement is created but it's not saved as part of another object.
      https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L260

      Benefit:
      When having access to the statements afterwards, all the following methods would be available:
      http://www.php.net/manual/en/class.pdostatement.php

      Most interesting are rowCount and error related methods.

        Activity

        Hide
        Steve Müller added a comment -

        Flip AFAIK you can use an SQL Logger for this which has to be set in the connection. The ORM testsuite makes use of this, too. See this example: https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Functional/OneToOneEagerLoadingTest.php#L155

        Show
        Steve Müller added a comment - Flip AFAIK you can use an SQL Logger for this which has to be set in the connection. The ORM testsuite makes use of this, too. See this example: https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Functional/OneToOneEagerLoadingTest.php#L155
        Hide
        Flip added a comment -

        Yes sure, but using a logger will be a strange way to pipe it back into business logic.

        For example it's possible to do remove() on a proxy so you don't know if the row was present or not.

        or another situation ..

        when dealing with concurrency .. somebody else might have deleted the row already ..

        Show
        Flip added a comment - Yes sure, but using a logger will be a strange way to pipe it back into business logic. For example it's possible to do remove() on a proxy so you don't know if the row was present or not. or another situation .. when dealing with concurrency .. somebody else might have deleted the row already ..

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Flip
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: