On Feb 25, 5:51 am, HARRY POTTRER <cp368...@ohio.edu> wrote: > Why not something like this: > > class Person(models.Model): > @classmethod > def male(cls): > return cls.objects.filter(gender='M') > > @classmethod > def female(cls): > return cls.objects.filter(gender='F') > > name = models.CharField(maxlength=20) > gender = models.CharField(maxlength=1) > > instead of defining a 'female' and 'male' custom managers as is > illustrated in the docs? Whenever I need to define 'table level' > functionality, I've always gone with the above method rather than > bother with a custom manager. What am I missing out on?
I don't find the doc example to be really that great FWIW. As far as I'm concerned, I'd define 'male' and 'female' as methods of the same custom manager. But anyway: - custom managers let you do much more than just adding a couple shortcuts, - custom managers can be used as "related" managers - that is, when traversing a relationship between to models. - personal tastes here, but I like having the 'table-level' operations properly namespaced. Point #2 can be really useful for some relatively complex models / relationships / bussiness rules, even if the way related_managers are currently created makes for sometimes a bit hackish code. My 2 cents... -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
