#7159 closed (wontfix)
Patch to add a --delete option to loaddata management command
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | Tools | Version: | dev |
| Severity: | Keywords: | ||
| Cc: | Triage Stage: | Design decision needed | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
The attached patch adds a '--delete' option to the loaddata command. This deletes any objects from the database that are not in the fixture. The fixture must contain at least one object of the class for the delete to run.
The result is that loaddata can now insert/update/delete to make a database match the fixture, becoming a sort of 'syncdata' command. A 'dumpdata' followed by 'loaddata --delete' effectively publishes one database onto another. We use this to publish our staging system to live.
The patch contains changes to management/commands/loadata.py, to docs/django-admin.txt and to tests/modeltests/fixtures/models.py. File fixture4.json goes in tests/modeltests/fixtures/fixtures/.
Attachments (3)
Change History (7)
by , 17 years ago
| Attachment: | loaddata-delete.diff added |
|---|
comment:1 by , 17 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
comment:3 by , 16 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
The way the feature is described in help text and options, it is equivalent to 'manage.py flush', followed by 'manage.py loaddata', which makes the proposed option redundant.
However, looking at the implementation, it is doing something quite different, and much more concerning. All you would need is one Foo object to accidentally get dropped into a fixture, and you lose all of your Foo data in the database. Alternately, you could have a model dependency between a model you _do_ want to flush, and one that you _dont_ want to flush; the cascading deletes from this option could cause you to lose data outside the classes that you think are going to be removed. I'm not in favour of adding commands or options that could lead to unexpected data loss on the scale that this command has the potential to do.
comment:4 by , 16 years ago
Thanks for taking the time to review this patch - I know 1.0 is keeping everyone very busy.
It is a bit like 'manage.py reset', followed by 'manage.py loaddata'. 'flush' doesn't work if you are loading accounts from the auth app.
The contenttypes initial data gets re-created, so after a flush the loaddata might fail because auth_permission.content_type_id foreign key points at a non-existent row.
I understand your concerns, if someone wanted to load only part of their database, and somehow specified --delete. This patch only applies for loading the entire database.
I have moved this to Django Snippets as a new 'syncdata' command: http://www.djangosnippets.org/snippets/926/
The downside is lots of the 'loaddata' code is duplicated.
The patch