It took me a while to understand manager better a little bit too.
Managers are pretty useful when you have a specific query / queryset
that will be common case, and it's more convenient to place that query
on one place and avoid repeating yourself.
For example, suppose you have a blogging app with a entry model. That
model has a boolean fiel, "public". You want to allow only public
entries to be viewed throughout the site. Instead of filtering for
public entries in a lot of places (views, feeds, sitemaps ):
entries = Entry.objects.filter(public=True)
It's just easier, and less error prone to say something like:
class EntryManager(Manager):
def public(self):
return self.filter(public=True)
Then, through the code you can just call:
entries = Entry.objects,public()
This is a simple case, but as your query gets more complex, the better
off you are.
Another case worth looking into, is custom sql. Sometimes django' ORM
is unable to make some queries (or they will be clumsy / have poor
performance) so you need to resort to hand written sql. Having that
code sit in one place only makes it more reusable (and easier to guard
against to sql injections, for example).
Django-tagging app has some well though uses of manager:
http://django-tagging.googlecode.com/svn/trunk/tagging/managers.py
Cheers,
Arthur
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
