Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#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: master
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:


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 ./ 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,

Change History (8)

comment:1 Changed 8 years ago by Paul McMillan

Triage Stage: UnreviewedAccepted

comment:2 Changed 8 years ago by Joshua Ginsberg <jag@…>

Resolution: wontfix
Status: newclosed

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.

comment:3 Changed 7 years ago by anonymous

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 Changed 7 years ago by anonymous

Resolution: wontfix
Status: closedreopened

comment:5 Changed 7 years ago by Aymeric Augustin

Resolution: wontfix
Status: reopenedclosed

#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 Changed 7 years ago by Karen Tracey

As documented ( 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 for the right way to address wontfix tickets where you question the decision.)

comment:7 Changed 7 years ago by anonymous

Oh, sorry about that.
Btw, usage help only says that we can explude APPs not models!

comment:8 in reply to:  7 Changed 7 years ago by Karen Tracey

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.

Note: See TracTickets for help on using tickets.
Back to Top