Closed senturio closed 11 years ago
Hm, thinking about it, I'm not even sure what the point of a TorrentGroup would be. Hold that thought.
The point of a TorrentGroup would be a generic way to represent a group of torrents so that functionality in other apps don't need to be tied down to apps implementing torrent meta data.
So if we implement a collages apps, it can just interact with torrent groups, and not have to care what application those groups belong to.
old plan is below - I'm updating the OP
We need a sane way to associate torrents with upload categories.
The way I envisage this is:
So an album would be a torrent group, with each individual release being an individual torrent, with its own associated metadata.
Problems I can see with this approach:
I honestly prefer keeping the grouping to the specific apps. For MusicUpload FK's a Release and I think that works out fine for this application but might be different in a different application. Its trivial to do a reverse FK lookup on a Release so im not sure what the point of a TorrentGroup would be
@Ell suggested this:
We made relatively comprehensive diagram of samples of categorization system.
Not all meta data is show, just enough to get everyone on the same page of what each term means
Please add in your thoughts or comments. The better we get this down before we start, the easier implementation will be.
I didn't understand the entity "Volume", does it represent collection of same type manga? If I am getting it right then we are missing some links from Volume (has many)-> mange. Same is the case with anime and Season i.e Season (has many)-> anime(episodes). Another observation, regarding the relation between Master and Artist, shouldn't we have (many to many) link?
Basically, a TorrentGroup (and by extension a Master, Season and Volume) each represent the same "thing" - a Volume is a single manga "book", a Season is the smallest unit we (as AB) allow uploading anime in, and a Master represents a single "album".
Master and Artist is supposed to be many to many. Releases, however, belong to a single master, and a MusicUpload is a single, specific ENCODING of that master, e.g.
This has now made it in, albeit with a few tweaks.
The "torrents" app has two models, Upload
and TorrentGroup
- each Torrent
must have an Upload
or a subclass and each Upload
belongs to a TorrentGroup
or a subclass.
Upload
and its subclasses hold metadata about a Torrent that is not directly related to its storage - think information that isn't required to regenerate the .torrent file, like what languages a video is subtitled in.
TorrentGroup
and its subclasses hold metadata about groups of torrents which contain the same thing, but in different formats, like what the album's name is, or how many episodes there were in the series.
I wonder why uploader
belongs to the Torrent
and not to the Upload
, any motivation for this?
@superbobry That's what I thought!
And yes, uploader
does belong to the Upload
in the version of code I committed. I need to clean stuff up and document it.
Leaving this issue open pending documentation!
Db model needs updation too, many of the references are missing..
I have attached the visual model
Completed in #50
We need a sane way to associate torrents with upload categories and additional metadata.
The way I envisage this now is (version 3):