Django

Code

Ticket #7566 (new)

Opened 5 months ago

Last modified 5 months ago

dumpdata command should not use model._default_manager.all()

Reported by: anonymous Assigned to: nobody
Milestone: Component: Serialization
Version: SVN Keywords: dumpdata
Cc: Triage Stage: Design decision needed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

dumpdata command should not use model._default_manager.all() for retrieving objects because model can use custom Manager with redefined .all() method.
better way for retrieving all objects is using QuerySet(model).all()

Attachments

dumpdata-fix.patch (0.9 kB) - added by anonymous on 06/29/08 05:29:25.
6155.diff (1.5 kB) - added by Karen Tracey <kmtracey@gmail.com> on 06/29/08 11:29:47.
Patch that updates doc as well

Change History

06/29/08 05:29:25 changed by anonymous

  • attachment dumpdata-fix.patch added.

06/29/08 11:29:47 changed by Karen Tracey <kmtracey@gmail.com>

  • attachment 6155.diff added.

Patch that updates doc as well

06/29/08 11:35:09 changed by Karen Tracey <kmtracey@gmail.com>

  • needs_better_patch changed.
  • stage changed from Unreviewed to Accepted.
  • needs_tests changed.
  • needs_docs changed.

Seems like a good idea, since I'd expect you'd normally want to dump everything even if the default manager excludes some records. I was unaware of that syntax for QuerySet creation when the fix for #6155 went in. But if this change is made then the doc note about the default manager being used needs to be deleted, since it won't be true any more. I updated the patch to do that as well.

06/29/08 18:56:26 changed by mtredinnick

  • stage changed from Accepted to Design decision needed.

I'm -1 on this change. If you have installed a default manager it's because they're the records you consider the "whole set" by default. And that's what dumpdata works with. If you wanted the whole set to be "everything", you wouldn't have overridden the default manager.

(follow-up: ↓ 4 ) 06/29/08 22:38:27 changed by Karen Tracey <kmtracey@gmail.com>

Eh, for my case I don't think of what the default manager returns as the "whole set". It's more the publicly-visible set. There's more in the database (which existed long before I put a Django front-end on it) than I care to expose via the website front-end, and I use excluding default managers to limit what can be seen in the normal case via the web site. That said, I've never actually used dumpdata (I backup/migrate/move the DB with database utilities directly) so I'm not particularly qualified to comment on how it should behave. But if I did need to use it, I think I'd want it to dump all the data.

(in reply to: ↑ 3 ) 06/30/08 00:53:51 changed by anonymous

Replying to Karen Tracey <kmtracey@gmail.com>:

Eh, for my case I don't think of what the default manager returns as the "whole set". It's more the publicly-visible set. There's more in the database (which existed long before I put a Django front-end on it) than I care to expose via the website front-end, and I use excluding default managers to limit what can be seen in the normal case via the web site. That said, I've never actually used dumpdata (I backup/migrate/move the DB with database utilities directly) so I'm not particularly qualified to comment on how it should behave. But if I did need to use it, I think I'd want it to dump all the data.

I agree with Karen Tracey. I use custom manager for creating versions of object, they makes visible only last version. If i execute dumpdata, i expect that all objects will be saved. Creating new method for filtering objects eliminates the need for a possible replace of the Manager, because that need to change all of the related sources.

Add/Change #7566 (dumpdata command should not use model._default_manager.all())




Change Properties
Action