Hi Shawn, Thank you for your response.
So is it correct then that if I assign a Manager object in my model, there will be no default Manager in model.object field? My book, The Definite Guide to Django, seem to suggest so, but it doesn't make sense. It essentially means you are breaking the ability to rely on a certain features existing in objects of a specific class. On Mar 14, 10:14 am, Shawn Milochik <sh...@milochik.com> wrote: > I can't address the first question because it was probably discussed > among the developers and was a design decision. > > As for the second, you don't *have to* create an 'objects' manager at > all. If you do nothing, you get a Manager() for free > by default, and because it has to be named *something*, it's 'objects' > -- just because that's what someone picked as a default long ago. > > Remember that 'objects' is not some special property of a Django > model. It's the name (by convention) that the default manager has. > It's like using **kwargs in a function -- it could just as easily be > **ponies, but most people just do it the way the community does it. > > If you choose to make your own manager then Django politely accepts > your decision and doesn't thrust the default upon you. > > You could always name your custom Manager 'objects' if you like. It's > even a good idea in some circumstances, like when you need to enforce > special filtering in your querysets. > > 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.
