Django

Code

Ticket #6155 (closed: fixed)

Opened 9 months ago

Last modified 9 months ago

Dumpdata Fails If There Is No Objects Attribute When Using a Custom Manager

Reported by: empty Assigned to: nobody
Milestone: Component: Core framework
Version: SVN Keywords: dumpdata
Cc: Triage Stage: Ready for checkin
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

Dumpdata fails if there is no objects default manager when Including your own custom manager. For example if we have a model that looks like:

class CategoryManager(models.Manager):
    def find_django(self):
        return self.filter(name='Django').order_by('name',)

class Category(models.Model):
    name = models.CharField(max_length=50)
    user = models.ManyToManyField(User)
    
    active_objects = CategoryManager()

Since there is no objects attribute on the model when the following dumpdata code runs it will fail with an attribute error:

        objects = []
        for app in app_list:
            for model in get_models(app):
                objects.extend(model.objects.all())

See http://groups.google.com/group/django-users/browse_thread/thread/7a58d619aea92d9c for more information.

The fix is to modify the block so it looks like this:

        objects = []
        for app in app_list:
            for model in get_models(app):
                objects.extend(model._default_manager.all())

Attachments

6155-1.diff (0.6 kB) - added by empty on 12/07/07 16:47:02.
Patches the dumpdata command
6155-2.diff (1.1 kB) - added by empty on 12/07/07 21:14:34.
Added documentation patch

Change History

12/07/07 16:47:02 changed by empty

  • attachment 6155-1.diff added.

Patches the dumpdata command

12/07/07 16:47:29 changed by empty

  • owner changed from nobody to empty.
  • needs_better_patch changed.
  • status changed from new to assigned.
  • needs_tests set to 1.
  • needs_docs changed.

12/07/07 18:47:39 changed by Simon G <dev@simon.net.nz>

  • stage changed from Unreviewed to Ready for checkin.

12/07/07 20:31:31 changed by empty

One issue to be aware of with the above solution is that it uses the same logic for the Admin piece. This means if the model looks something like:

class Category(models.Model):
    name = models.CharField(max_length=50)
    user = models.ManyToManyField(User)
    
    active_objects = CategoryManager()
    objects = models.Manager()

The dumpdata will dump from the default manager (in this case CategoryManager?) instead of the models.Manager(). If the get_query_set() method is modified to filter records in a special way and the custom manager appears first in the model class then dumpdata will only provide the result of that modified queryset.

If this is okay the above solution should work fine. If it's not then we'll need to check if the objects attribute is available and use that otherwise use _default_manager.

12/07/07 21:14:34 changed by empty

  • attachment 6155-2.diff added.

Added documentation patch

12/07/07 21:17:24 changed by empty

  • owner changed from empty to nobody.
  • status changed from assigned to new.
  • has_patch set to 1.
  • needs_tests deleted.

I added documentation to the django-admin.py docs to explain that the default manager is used. After looking through tests I really couldn't find anything that was not already covered. The tests for covering the default manager already exist in the custom_managers tests. If there's something that you would like me to add, please let me know and I'll be happy to do it.

12/17/07 03:09:08 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

(In [6932]) Fixed #6155 -- Fixed dumpdata to work with the default model manager (necessary for the rare cases when the 'objects' manager might not even exist). Based on a patch from Michael Trier.


Add/Change #6155 (Dumpdata Fails If There Is No Objects Attribute When Using a Custom Manager)




Change Properties
Action