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 #1353

New Issue

admin · 2026-01-22T13:11:24+01:00

admin commented

2026-01-22 13:11:24 +01:00

Originally created by @doctrinebot on GitHub (Mar 28, 2011).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user dalvarez:

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.

Originally created by @doctrinebot on GitHub (Mar 28, 2011). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user dalvarez: 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.

admin added the Bug label 2026-01-22 13:11:24 +01:00

admin closed this issue

2026-01-22 13:11:24 +01:00

admin commented

2026-01-22 13:11:25 +01:00

@doctrinebot commented on GitHub (Mar 28, 2011):

depends on DDC-1266: doctrine drop sequence twice

@doctrinebot commented on GitHub (Mar 28, 2011): - depends on [DDC-1266: doctrine drop sequence twice](http://www.doctrine-project.org/jira/browse/DDC-1266)

admin commented

2026-01-22 13:11:26 +01:00

@doctrinebot commented on GitHub (Mar 28, 2011):

Comment created by dalvarez:

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.

@doctrinebot commented on GitHub (Mar 28, 2011): Comment created by dalvarez: 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.

admin commented

2026-01-22 13:11:26 +01:00

@doctrinebot commented on GitHub (May 1, 2011):

Comment created by @beberlei:

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

@doctrinebot commented on GitHub (May 1, 2011): Comment created by @beberlei: I changed alot in the dropSchema command, can you try again? The problem here is with all the foreign keys.

admin commented

2026-01-22 13:11:28 +01:00

@doctrinebot commented on GitHub (May 8, 2011):

Comment created by dalvarez:

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.

@doctrinebot commented on GitHub (May 8, 2011): Comment created by dalvarez: 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.

admin commented

2026-01-22 13:11:28 +01:00

@doctrinebot commented on GitHub (May 8, 2011):

Comment created by dalvarez:

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.

@doctrinebot commented on GitHub (May 8, 2011): Comment created by dalvarez: 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.

admin commented

2026-01-22 13:11:28 +01:00

@doctrinebot commented on GitHub (Jun 19, 2011):

Comment created by @beberlei:

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

@doctrinebot commented on GitHub (Jun 19, 2011): Comment created by @beberlei: This should be fixed now, SchemaTool didnt handle sequence removal correctly before. Can you verify?

admin commented

2026-01-22 13:11:30 +01:00

@doctrinebot commented on GitHub (Jun 19, 2011):

Comment created by dalvarez:

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.

@doctrinebot commented on GitHub (Jun 19, 2011): Comment created by dalvarez: 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.

admin commented

2026-01-22 13:11:30 +01:00

@doctrinebot commented on GitHub (Jul 10, 2011):

Comment created by mathroc:

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

@doctrinebot commented on GitHub (Jul 10, 2011): Comment created by mathroc: maybe it's related to this bug : http://www.doctrine-project.org/jira/browse/[DDC-1266](http://www.doctrine-project.org/jira/browse/DDC-1266) I just found this piece of code that mutes exceptions... ``` java 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

admin commented

2026-01-22 13:11:31 +01:00

@doctrinebot commented on GitHub (Jul 20, 2011):

Comment created by dalvarez:

@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.

@doctrinebot commented on GitHub (Jul 20, 2011): Comment created by dalvarez: @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.

admin commented

2026-01-22 13:11:32 +01:00

@doctrinebot commented on GitHub (Oct 31, 2011):

Comment created by @beberlei:

Fixed

@doctrinebot commented on GitHub (Oct 31, 2011): Comment created by @beberlei: Fixed

admin commented

2026-01-22 13:11:33 +01:00

@doctrinebot commented on GitHub (Oct 31, 2011):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Oct 31, 2011): Issue was closed with resolution "Fixed"

admin referenced this issue