I also have a copy of that book, and I believe that what you're
referring to pages 197 and 198.
Here is what the authors are doing there:
1. Creating a special manager that does one thing -- return a
filtered subset of the model instances.
2. Creating a replacement 'objects' manager since otherwise the
custom manager would become the default (and only) manager.
The reason for this is not because you *have to* always have a manager
named 'objects.' The reason is that the custom manager created in that
example was a specialized one that is only useful for certain
situations. So you need a "normal" one for everything else. Also, that
"normal" one has to be declared as the first manager in the model
because Django apps (including the admin) will take the first manager
as the default.
To answer your question specifically, if you create a custom manager
(and name it anything other than 'objects') in your model, then your
model will not have an 'objects.' However, the Django admin (and any
other software which uses the default manager instead of hard-coding
'objects' in the querysets) will work fine. Other code will have to
refer to the name you gave your manager.
Shawn
--
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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
