Why use "through" argument for ManyToManyField in Django models?

Question

Looking through the Django docs and trying to figure out the use of the "through" argument. Here is a link to the doc.

The example:

class Person(models.Model):
    name = models.CharField(max_length=128)

    def __unicode__(self):
        return self.name

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, through='Membership')

    def __unicode__(self):
        return self.name

class Membership(models.Model):
    person = models.ForeignKey(Person)
    group = models.ForeignKey(Group)
    date_joined = models.DateField()
    invite_reason = models.CharField(max_length=64)

Why is the "members" attribute of Group even needed? Isn't the 'group' ForeignKey of Membership enough to follow the relation and access that information?

Answer 1

I think you're thinking a little too literally about this. Let's say you didn't use through:

class Person(models.Model):
    name = models.CharField(max_length=128)

    def __unicode__(self):
        return self.name

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person)

    def __unicode__(self):
        return self.name

Django, behind the scenes, essentially creates the following model for you:

class GroupPerson(models.Model)
    group = models.ForeignKey(Group)
    person = models.ForeignKey(Person)

The reason for creating a Membership model is to add extra data that the default model Django automatically creates wouldn't have by default, but since you're no longer using the default, you have to tell Django that, using through. Basically, you're preserving the API Django provides for ManyToManyFields.

Answer 2

The reason why one would do this is so that Group has a field for this relationship, rather than having to follow the relationship back through its membership_set.

If nothing else, this can make writing queries simpler. At the very least, this can make a programmer's life easier, and code easier to read. A sufficiently optimising ORM would be able to generate appropriate indices to speed up such access (and unless I'm very much mistaken, django does indeed do that; or at least South does).