#23833 closed New feature (wontfix)
Add a management command to drop all tables
Reported by: | Mattia Procopio | Owned by: | Mattia Procopio |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Sometimes it happeens that I need to delete all tables within my database, dropping tables manually is a boring procedure. Would it be good to add such a feature as command?
Change History (17)
comment:1 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
comment:3 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:4 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 10 years ago
For apps without migrations, you could something like: ./manage.py sqlclear | ./manage.py dbshell
I think. Apps with migrations only support sqlmigrate
and sqlflush
though. I am not sure if there is a good reason not to support sqlclear
so this is still possible.
comment:6 by , 10 years ago
With migrations you can just reverse the migrations with ./manage.py migrate appname zero
, which will clear everything as required.
comment:7 by , 10 years ago
Faced with a similar problem, I came up with this snippet that will clear only those apps that are not django.contrib.
(of course, this is before migrations came around). Might give some ideas:
echo 'from django.conf import settings; print settings.INSTALLED_APPS; quit();' | \ python manage.py shell --plain 2>&1 | \ tail -n1 | sed -r "s|^.*\((.*)\).*$|\1|; s|[',]| |g; s|django\.contrib\.||g" | \ xargs python manage.py sqlclear | \ python manage.py dbshell && python manage.py syncdb
comment:8 by , 10 years ago
@MattBlack85: You said in the ticket that "this is easy using SQLite", but I don't see how that fits with the clarification in comment:1. Do you care to elaborate?
comment:9 by , 10 years ago
sure, I didn't explain well, I'm goin to update the description. I was meaning "with SQLite usually the db can be easily dropped with a rm and recreated" but yeah, that's not dropping table
comment:10 by , 10 years ago
Description: | modified (diff) |
---|
comment:11 by , 10 years ago
I guess I didn't explain my question clearly enough:
"drop database" on other backends is just as easy as "rm" with SQLite, but that does not seem satisfactory to you. According to comment:1, your intention is to drop the Django-managed tables only, but apparently that does not apply for SQLite because there, dropping everything is allowed.
So -- is the comparison to SQLite at all relevant? The feature request is valid without it, and less clear with it.
comment:12 by , 10 years ago
I'd like to manage drop table for SQLite too. I'll drop the reference to SQLite at all to make this more clear.
comment:13 by , 10 years ago
Description: | modified (diff) |
---|
comment:14 by , 9 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Summary: | drop all tables → Add a management command to drop all tables |
Closing per comment 6, "With migrations you can just reverse the migrations with ./manage.py migrate appname zero
, which will clear everything as required."
comment:15 by , 9 years ago
I tried this but it doesn't work with non-reversable migrations... raise Migration.IrreversibleError("Operation %s in %s is not reversible" % (operation, self))
It would be handy to be able to clear a database even when the migrations cannot be reversed
comment:16 by , 9 years ago
I personally don't think this is a common enough case that we need to add something to core. Feel free to raise it on the DevelopersMailingList for further discussion. Obviously if it cannot be done as a third-party command for some reasons, there might be a stronger justification for making some change in core to ease that.
comment:17 by , 9 years ago
Resolution: | worksforme → wontfix |
---|
Adjust reason for closing per https://code.djangoproject.com/ticket/23833#comment:16
Talked to the author of the ticket. Add clarifying comment:
The main concern is that in the same database you may have tables belonging and non-belonging the django project. In that scenario: