I have a very basic question about django.db.models
.
In this official django tutorial, if you search for word \"choice_set
\", you will see tha
You can get a full list of the attributes of a class, both those you defined and the ones that are defined for it, using the dir
function, just do
dir(Poll)
You'll end up with something that looks a little like (though not exactly- I'm constructing it in a roundabout way):
['DoesNotExist', 'MultipleObjectsReturned', '__class__', '__delattr__',
'__dict__', '__doc__', '__eq__', '__format__', '__getattribute__', '__hash__',
'__init__', '__metaclass__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__unicode__',
'__weakref__', '_base_manager', '_default_manager', '_deferred', '_get_FIELD_display',
'_get_next_or_previous_by_FIELD', '_get_next_or_previous_in_order', '_get_pk_val',
'_get_unique_checks', '_meta', '_perform_date_checks', '_perform_unique_checks', '_set_pk_val',
'clean', 'clean_fields', 'curve_set', 'date_error_message', 'delete', 'full_clean', 'objects',
'pk', 'prepare_database_save', 'save', 'save_base', 'choice_set',
'serializable_value', 'unique_error_message', 'validate_unique']
That's a lot of values! We can see exceptions like DoesNotExist
and MultipleObjectsReturned
, along with the most important one, objects
. But some of these attributes weren't added by Django. If you do dir(object())
you'll find a list of the attributes in all objects:
['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']
Mostly you can ignore the ones that start and end with two __
. Most of the others were added by Django.
As for how and where it actually sets these: Django sets most of each new model's attributes dynamically using the models.Model
metaclass. The first thing to know is that you can add a member or method to a class dynamically, using the setattr
function:
class X:
pass
setattr(X, "q", 12)
print X.q # prints 12
That's how it can create new attributes just based on the name of your attribute.
In the tutorial, the important line that allows it to start defining these extra attributes is:
class Poll(models.Model):
This means that the Poll
class inherits the models.Model
class (which belongs to Django). Inheritance has many useful properties- basically, the Poll
class inherits some of the behavior that the models.Model
class has set up- but the place it defines most of these new attributes is in the Model metaclass. Metaclasses are a tricky concept, but basically they serve as a recipe for creating new classes, and by defining one, Django gets to step in right when the models.py
metaclass is being defined, and define any new .
The code for the Model metaclass can be found here (starting at line 55)- it's a set of code that is actually step-by-step creating a class from the ground up. As complicated as it looks, you can get a lot out of it just by looking at the variable names. For instance, look at the promisingly named add_to_class
method:
def add_to_class(cls, name, value):
if hasattr(value, 'contribute_to_class'):
value.contribute_to_class(cls, name)
else:
setattr(cls, name, value)
Outside of the one special case of 'contribute_to_class
(not important for your interest), this is a method for adding a new attribute (such as a method or a member) to a class. The places where it is called give us hints of what it is adding:
class.add_to_class('DoesNotExist', subclass_exception(str('DoesNotExist') ......
Here it is adding the DoesNotExist
exception, which is what is returned if you ask for a Poll
that doesn't exist. (See for yourself by running Poll.objects.get(pk=1337)
, or directly by typing in Poll.DoesNotExist
).
But Django is actually even more complicated than that. The specific _set
attribute you're asking about isn't constructed for every model- it's created when a field is related to another by a ForeignKey
(as are your Poll
and Choice
). The various places where it gets assigned are very complicated, but it basically all comes back to this get_accessor_name
function in related.py
def get_accessor_name(self):
# This method encapsulates the logic that decides what name to give an
# accessor descriptor that retrieves related many-to-one or
# many-to-many objects. It uses the lower-cased object_name + "_set",
# but this can be overridden with the "related_name" option.
if self.field.rel.multiple:
# If this is a symmetrical m2m relation on self, there is no reverse accessor.
if getattr(self.field.rel, 'symmetrical', False) and self.model == self.parent_model:
return None
return self.field.rel.related_name or (self.opts.object_name.lower() + '_set')
else:
return self.field.rel.related_name or (self.opts.object_name.lower())
That's just coming up with the name- tracing it back to figure out how it gets added to the class is no small feat. But I hope you see from this that Django has many chances to add attributes like this.