Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1082

On PostgreSQL "doctrine orm:schema-tool:drop --force" will not delete all tables created by orm:schema-tool:create and still report success

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.1.3
    • Component/s: Tools
    • Security Level: All
    • Labels:
      None

      Description

      doctrine orm:schema-tool:drop --force

      will report success even if there are still tables in the schema. The tables remaining are regular tables pertaining to the schema, which was originally created by the doctrine tools, and the tables should have be deleted regularly.

      Repeating the command will delete all tables as expected.

      I tried this with PostgreSQL 8.4.7 on Debian/Linux 5.0.

      Btw, I think there should be another issue priority to assign to bugs like these. I made this a major bug, because in the existing priority system, according to the issue priority definitions, I think this closer to a major bug than to a minor bug because the system gives wrong information to the user, so that the underlying problem manifests in subsequent errors only, and is hard to detect if you believe the console tool's output. Still, it is easy to work around it. I would deem this a "normal" bug. "Major" seems to severe while "minor" seems not severe enough. Do you think it is worthwhile to introduce "normal"? This could help distinguish the real "major" bugs from those just declared as "major" because there was no option to declare them normal, and maybe give you a better focus on the more important bugs.

        Issue Links

          Activity

          Hide
          Daniel Alvarez Arribas added a comment - - edited

          In my database, out of 56 tables, 17 will not be deleted. I tried to find something these tables have in common, but could not find a pattern. After repeating the drop-schema command, three tables remain, including the top-most base table in the inheritance hierarchy, and a table referenced by it. Repeating the drop-schema command again drops those tables, too.

          Show
          Daniel Alvarez Arribas added a comment - - edited In my database, out of 56 tables, 17 will not be deleted. I tried to find something these tables have in common, but could not find a pattern. After repeating the drop-schema command, three tables remain, including the top-most base table in the inheritance hierarchy, and a table referenced by it. Repeating the drop-schema command again drops those tables, too.
          Hide
          Benjamin Eberlei added a comment -

          I changed alot in the dropSchema command, can you try again? The problem here is with all the foreign keys.

          Show
          Benjamin Eberlei added a comment - I changed alot in the dropSchema command, can you try again? The problem here is with all the foreign keys.
          Hide
          Daniel Alvarez Arribas added a comment -

          Ok, thanks.

          I tried again, now with Doctrine version 2.04.

          I updated the Doctrine 2 installation to version 2.04, then recreated the complete database from scratch using doctrine orm:schema-tool:create --force.
          Before recreating the database, I manually, dropped all tables in the database, and verified all tables were gone. I also regenerated the proxy classes, just in case it could have any effect.

          The 86 tables have been created, as expected.

          Then I tried to drop the database by calling doctrine orm:schema-tool:drop --force.

          After using the command, there are still 17 tables remaining.

          Overall, the result seems to be unaffected by the upgrade to the latest minor version.

          Show
          Daniel Alvarez Arribas added a comment - Ok, thanks. I tried again, now with Doctrine version 2.04. I updated the Doctrine 2 installation to version 2.04, then recreated the complete database from scratch using doctrine orm:schema-tool:create --force. Before recreating the database, I manually, dropped all tables in the database, and verified all tables were gone. I also regenerated the proxy classes, just in case it could have any effect. The 86 tables have been created, as expected. Then I tried to drop the database by calling doctrine orm:schema-tool:drop --force. After using the command, there are still 17 tables remaining. Overall, the result seems to be unaffected by the upgrade to the latest minor version.
          Hide
          Daniel Alvarez Arribas added a comment -

          One thing that works now, though, is that calling doctrine orm:schema-tool:drop --force repeatedly, will also delete the 17 tables remaining after the first call.

          So it did get better, although it does not work the first time it gets called, and still wrongly reports success the first time.

          Show
          Daniel Alvarez Arribas added a comment - One thing that works now, though, is that calling doctrine orm:schema-tool:drop --force repeatedly, will also delete the 17 tables remaining after the first call. So it did get better, although it does not work the first time it gets called, and still wrongly reports success the first time.
          Hide
          Benjamin Eberlei added a comment -

          This should be fixed now, SchemaTool didnt handle sequence removal correctly before. Can you verify?

          Show
          Benjamin Eberlei added a comment - This should be fixed now, SchemaTool didnt handle sequence removal correctly before. Can you verify?
          Hide
          Daniel Alvarez Arribas added a comment -

          Hey Ben,

          I am currently travelling and do not have access to any development system. I will be back home by July, 1st and will have a look at this and let you know. Thanks for fixing it.

          Show
          Daniel Alvarez Arribas added a comment - Hey Ben, I am currently travelling and do not have access to any development system. I will be back home by July, 1st and will have a look at this and let you know. Thanks for fixing it.
          Hide
          Mathieu Rochette added a comment - - edited

          maybe it's related to this bug : http://www.doctrine-project.org/jira/browse/DDC-1266

          I just found this piece of code that mutes exceptions...

              public function dropSchema(array $classes)
              {
                  $dropSchemaSql = $this->getDropSchemaSQL($classes);
                  $conn = $this->_em->getConnection();
          
                  foreach ($dropSchemaSql as $sql) {
                      try {
                          $conn->executeQuery($sql);
                      } catch(\Exception $e) {
                          
                      }
                  }
              }
          

          maybe I'm missing something but even after reading the function comment this seems like a bad idea.
          if dropTable is called within a transaction, the transaction will be aborted and the function will still return as if sucessful

          Show
          Mathieu Rochette added a comment - - edited maybe it's related to this bug : http://www.doctrine-project.org/jira/browse/DDC-1266 I just found this piece of code that mutes exceptions... public function dropSchema(array $classes) { $dropSchemaSql = $ this ->getDropSchemaSQL($classes); $conn = $ this ->_em->getConnection(); foreach ($dropSchemaSql as $sql) { try { $conn->executeQuery($sql); } catch (\Exception $e) { } } } maybe I'm missing something but even after reading the function comment this seems like a bad idea. if dropTable is called within a transaction, the transaction will be aborted and the function will still return as if sucessful
          Hide
          Daniel Alvarez Arribas added a comment -

          @Mathieu: Yes, that could very well be the root cause.

          @Benjamin: I verified that the error is still there, now with Doctrine 2.1 and PostgreSQL 8.4. The command line tool (doctrine orm:schema-tool:drop --force) still wrongly reports success, in spite of several tables remaining in the schema.

          Once I remove the try-catch-construct mentioned by Mathieu above (leaving the try block's content intact, of course), and reissue the command, there are exceptions. E.g.:

          PDOException SQLSTATE[42P01]: Undefined table: 7 ERROR: sequence "some_random_sequence_seq" does not exist.

          I believe that the intention of the try-catch-block above is to mute exactly that type of error, since it should not make any difference if something that is not there could not be deleted, because, after all, it is gone anyway. Unfortunately, it actually does make a difference in case several SQL-DDL commands are combined into a single call, because if any command in the call fails and raises an exception, all following commands in the same call will not be executed. I have not analyzed this further, but I think there is something smelly here.

          Show
          Daniel Alvarez Arribas added a comment - @Mathieu: Yes, that could very well be the root cause. @Benjamin: I verified that the error is still there, now with Doctrine 2.1 and PostgreSQL 8.4. The command line tool (doctrine orm:schema-tool:drop --force) still wrongly reports success, in spite of several tables remaining in the schema. Once I remove the try-catch-construct mentioned by Mathieu above (leaving the try block's content intact, of course), and reissue the command, there are exceptions. E.g.: PDOException SQLSTATE [42P01] : Undefined table: 7 ERROR: sequence "some_random_sequence_seq" does not exist. I believe that the intention of the try-catch-block above is to mute exactly that type of error, since it should not make any difference if something that is not there could not be deleted, because, after all, it is gone anyway. Unfortunately, it actually does make a difference in case several SQL-DDL commands are combined into a single call, because if any command in the call fails and raises an exception, all following commands in the same call will not be executed. I have not analyzed this further, but I think there is something smelly here.
          Hide
          Benjamin Eberlei added a comment -

          Fixed

          Show
          Benjamin Eberlei added a comment - Fixed

            People

            • Assignee:
              Benjamin Eberlei
              Reporter:
              Daniel Alvarez Arribas
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: