#13816 closed Uncategorized (wontfix)
dumpdata should not attempt to dump non-managed models
Reported by: | Florian Le Goff | Owned by: | nobody |
---|---|---|---|
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
Following my e-mail to django-users ( <95be434a-5b33-4a03-988a-d8917a63da09@…> / Fri, 18 Jun 2010 02:37:55 -0700 (PDT) ) ;
I do think that ./manage.py dumpdata <app> should not attempt to dump data from non-managed models. An alternate solution may be a --skip-non-managed-models flags.
For the record, running dumpdata on an app using non-managed models currently fails while throwing a django.db.utils.DatabaseError .
Thanks for the attention,
F.
Change History (8)
comment:1 by , 15 years ago
Component: | Uncategorized → django-admin.py |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 by , 14 years ago
Easy pickings: | unset |
---|---|
Severity: | → Normal |
Type: | → Uncategorized |
Closing this bug doesn't make any sense to me.
If tables are marked has unmanaged why django wants to dump/load data from/to those tables?
That's why they are marked has unmanaged in first place! Because there's no responsibility of django managing those tables.
Also, I didn't understood (and wasn't explained) what django really does. If we need to dump data from an application that has at least one unmanaged table (others are normal managed) what django currently does in the dumpdata command? Does it dump data from unmanaged tables also?
comment:4 by , 14 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:5 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
#15967 was a duplicate.
Also, I see that two core devs decided to close this ticket as wontfix.
Dear anonymous, you shouldn't reopen tickets closed by core developers. Please bring up the subject on django-developers (with good arguments).
Closing again.
comment:6 by , 14 years ago
As documented (http://docs.djangoproject.com/en/1.3/ref/models/options/#managed) the only thing that managed=False does is prevent Django from creating the table on syncdb and destroying it on reset. In all other ways the model is treated the same as any other model, so I don't believe it should be surprising that dumpdata will attempt to read data from the table. If you don't want that model included during dumpdata, then exclude it. I think it would be far more surprising (and far more likely to cause enexpected data loss) to have unmanaged models automatically excluded from dumpdata processing.
(Also please read the contributing doc http://docs.djangoproject.com/en/1.3/internals/contributing/#reporting-bugs for the right way to address wontfix tickets where you question the decision.)
follow-up: 8 comment:7 by , 14 years ago
Oh, sorry about that.
Btw, usage help only says that we can explude APPs not models!
comment:8 by , 14 years ago
Replying to anonymous:
Btw, usage help only says that we can explude APPs not models!
Then you may be running a version that supports only apps. With 1.3 I get:
-e EXCLUDE, --exclude=EXCLUDE An appname or appname.ModelName to exclude (use multiple --exclude to exclude multiple apps/models).
The version marker in the docs notes this is new with 1.3.
Per alex and mattmcc the user's expectations are not shared. It is the responsibility of the administrator to ensure the creation and destruction of unmanaged models, and Django rightly throws an error when the administrator has not created a table for which a model exists. Apologies to madflo for the inconvenience until #12775 is committed.