On Jun 24, 7:01 pm, Sector7B <joe.greenaw...@gmail.com> wrote: > Thanks for the feedback and the link, all good stuff! > I looked at what i had written, and I think a better way to ask the > question is: > What are the mechanics behind providing "choice_set.all()"? > For example i have a field "choice" so having "_set" (concatenated) is > that generated when i run syncdb somewhere, or is that dynamically > interpreted at runtime? > My background leads me to think there would be a choice.set().all(), > the "_set" seems weird (to me) unless its generated. > > Thanks again, > -j >
It's dynamically generated when the model class is defined. Fields can define a 'contribute_to_class' method, which is responsible for defining dynamic properties/methods on the model class. When the field is instantiated - which happens when the class is defined, ie when its module is first imported - the field's contribute_to_class method is executed and the related manager is created. You can see the code for this in django.db.models.fields.related.RelatedField. (Actually you'll see that contribute_to_class calls do_related_class, which calls contribute_to_related_class, which sets up the descriptor on the related model.) A very good guide to all this is Marty Alchin's book Pro Django, which goes into depth as to how the model metaclasses work. -- DR. -- 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.
