[Django] #23833: drop all tables
Django
--------------------------------------------+--------------------
Reporter: MattBlack85 | Owner: nobody
Type: New feature | Status: new
Component: Core (Management commands) | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------------+--------------------
Sometimes it happeens that I need to delete all tables within my database.
While this is easy using SQLite, it's a boring procedure using another
backend. Would it be good to add such a feature as command?
--
Ticket URL: <https://code.djangoproject.com/ticket/23833>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner: nobody
Type: New feature | Status: closed
Component: Core (Management | Version: master
commands) | Resolution: fixed
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by yamila-moreno):
* status: new => closed
* needs_docs: => 0
* resolution: => fixed
* needs_tests: => 0
* needs_better_patch: => 0
Comment:
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:
- dropdb : would cause losing all tables even those I would like to keep
- entering the db-shell and deleting tables one by one is boring and it's
easy to make a mistake
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
commands) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by yamila-moreno):
* status: closed => new
* resolution: fixed =>
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:2>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
commands) | Resolution:
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by yamila-moreno):
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Component: Core (Management | Status: assigned
commands) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MattBlack85):
* owner: nobody => MattBlack85
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by andrewgodwin):
With migrations you can just reverse the migrations with `./manage.py
migrate appname zero`, which will clear everything as required.
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by burhan):
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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by shaib):
@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?
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by MattBlack85):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Description changed by MattBlack85:
Old description:
> Sometimes it happeens that I need to delete all tables within my
> database. While this is easy using SQLite, it's a boring procedure using
> another backend. Would it be good to add such a feature as command?
New description:
Sometimes it happeens that I need to delete all tables within my database.
While with SQLite the db can be easily dropped togheter with the tables,
it's still a boring procedure dropping tables manually using another
backend. Would it be good to add such a feature as command?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by shaib):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by MattBlack85):
I'd like to manage drop table for SQLite too. I'll drop the reference to
SQLite at all to make this more clear.
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
Type: New feature | MattBlack85
Component: Core (Management | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Description changed by MattBlack85:
Old description:
> Sometimes it happeens that I need to delete all tables within my
> database. While with SQLite the db can be easily dropped togheter with
> the tables, it's still a boring procedure dropping tables manually using
> another backend. Would it be good to add such a feature as command?
New description:
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?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:13>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
| MattBlack85
Type: New feature | Status: closed
commands) | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: assigned => closed
* resolution: => worksforme
Comment:
Closing per comment 6, "With migrations you can just reverse the
migrations with `./manage.py migrate appname zero`, which will clear
everything as required."
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
| MattBlack85
Type: New feature | Status: closed
Component: Core (Management | Version: master
commands) | Resolution:
Severity: Normal | worksforme
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by thenewguy):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:15>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
| MattBlack85
Type: New feature | Status: closed
Component: Core (Management | Version: master
commands) | Resolution:
Severity: Normal | worksforme
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:16>
Django
-------------------------------------+-------------------------------------
Reporter: MattBlack85 | Owner:
| MattBlack85
Type: New feature | Status: closed
Component: Core (Management | Version: master
commands) |
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by thenewguy):
* resolution: worksforme => wontfix
Comment:
Adjust reason for closing per
https://code.djangoproject.com/ticket/23833#comment:16
--
Ticket URL: <https://code.djangoproject.com/ticket/23833#comment:17>