Dropping all tables + more

4,739 views
Skip to first unread message

Russ

unread,
Sep 23, 2011, 1:35:22 PM9/23/11
to sqlal...@googlegroups.com
Is the DropEverything recipe still the best way to drop everything via SQLAlchemy?


The recipe is ancient (almost a year old! :) ) and I just want to check if there is a better way now.

How I got here (for searchability)...

When doing unit testing on a primarily PostgreSQL application I routinely drop all tables in a database with this:

def DropAllTables(EngineURL):
    import sqlalchemy
    engine = sqlalchemy.create_engine(EngineURL)
    meta = sqlalchemy.MetaData(engine)
    meta.reflect()
    meta.drop_all()

However, I've recently added tables that refer to each other (which required using "use_alter" on the ForeignKey definition to avoid problems) and drop_all ends up raising a CircularDependencyError.  In trying to resolve this I found these useful links, which ultimately led me to the DropEverything recipe:


Michael Bayer

unread,
Sep 23, 2011, 10:53:40 PM9/23/11
to sqlal...@googlegroups.com
On Sep 23, 2011, at 1:35 PM, Russ wrote:

Is the DropEverything recipe still the best way to drop everything via SQLAlchemy?


The recipe is ancient (almost a year old! :) ) and I just want to check if there is a better way now.

I still use it, the APIs it's using are still current so I think its good to go.  I don't recall if it might need adjustments for certain circumstances so let me know if it works for you.


Russell Warren

unread,
Sep 24, 2011, 10:44:11 PM9/24/11
to sqlal...@googlegroups.com
I should have mentioned that in my first post... it worked fine as-is for me with absolutely no circular reference problem.

--
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To post to this group, send email to sqlal...@googlegroups.com.
To unsubscribe from this group, send email to sqlalchemy+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.

Russ

unread,
Dec 14, 2012, 9:17:11 PM12/14/12
to sqlal...@googlegroups.com
I have just updated SQLAlchemy from 0.7.8 to 0.8.0b2 (the current pip default) and the DropEverything recipe has stopped working.  The problem is on the DropTable line with this error :

sqlalchemy.exc.InternalError: (InternalError) cannot drop table test_list_name because other objects depend on it

I'm currently trying to figure out how to fix it with the hint it gives ("HINT:  Use DROP ... CASCADE to drop the dependent objects too."), but at the moment it is not clear to me how to do this.  I'm out of my depth when it comes to schema definition language changes.

Does anyone know a quick fix?

Michael Bayer

unread,
Dec 14, 2012, 11:18:32 PM12/14/12
to sqlal...@googlegroups.com
Nothing has changed regarding that recipe and I just ran it on a small set of tables against Postgresql (which I can see is the DB you're using) and it runs fine.  Are you sure the identical schema *does* drop completely when this recipe is run directly with 0.7.8 ?    Can you provide the structure of the schema which can't be dropped ?


--
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/okypK5IgUaoJ.

Russell Warren

unread,
Dec 19, 2012, 11:45:33 AM12/19/12
to sqlal...@googlegroups.com
On Fri, Dec 14, 2012 at 11:18 PM, Michael Bayer <mik...@zzzcomputing.com> wrote:
Nothing has changed regarding that recipe and I just ran it on a small set of tables against Postgresql (which I can see is the DB you're using) and it runs fine.  Are you sure the identical schema *does* drop completely when this recipe is run directly with 0.7.8 ?    Can you provide the structure of the schema which can't be dropped ?

Sorry - it seems that this was a phantom problem.

I dialed my versions and DB back to try and figure out where things went wrong, and everything was working.  Then I re-upgraded... and everything was still working.  ie: DropEverything still works perfectly, as you expected.  I have absolutely no idea what was causing the failure before... I can only assume my DB and/or code was in a weird state somehow?

Reply all
Reply to author
Forward
0 new messages