How Torrent Models Work

Basically, the system works like this:

In the most basic sense, you need to worry about:

• Upload Groups (UploadGroup subclasses)
• Uploads (Upload subclasses)

On both of these (i.e. on your own subclasses of UploadGroup and Upload), you can attach your own metadata, just like in a normal model.

However, in some cases, you might need to stick more grouping in to your torrents.

For example, in the music app, we have the following models:

• MusicUpload (Upload subclass)
• Master (UploadGroup subclass)

But, we also have:

• Release (DescendingModel subclass)

This is because each Master may have multiple Releases - think along the lines of if you have a single album (a Master) which has an original version (an Release) and a Japan-only version with extra tracks (a different Release). Each MusicUpload represents one particular encoding of one particular Release, which belongs to a Master.

Note, however, if you do this, you need to make two additional changes to your models:

• On your UploadGroup subclass, you must override get_child_model to return the class you're inserting
• On the class you're inserting, you must define a parent ForeignKey pointing at the parent class (or use a GenericForeignKey)
• On the class you're inserting, you must also override get_child_model to return the Upload subclass beneath it

These steps help to establish a hierarchy of models that can be traversed up and down.

Here's my helpful diagram: