search

wafflesfm / batter

It makes Waffles.
Other
83 stars 18 forks source link

Core model design #15

Closed senturio closed 11 years ago

senturio commented 11 years ago

We need a sane way to associate torrents with upload categories and additional metadata.

The way I envisage this now is (version 3):

Diagram

senturio commented 11 years ago

Hm, thinking about it, I'm not even sure what the point of a TorrentGroup would be. Hold that thought.

endoscient commented 11 years ago

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.

senturio commented 11 years ago

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.

Playground 1

Problems I can see with this approach:

Ell commented 11 years ago

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

senturio commented 11 years ago

@Ell suggested this:

mockup

endoscient commented 11 years ago

We made relatively comprehensive diagram of samples of categorization system.

Diagram

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.

addmaths07 commented 11 years ago

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?

senturio commented 11 years ago

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.

senturio commented 11 years ago

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.

superbobry commented 11 years ago

I wonder why uploader belongs to the Torrent and not to the Upload, any motivation for this?

senturio commented 11 years ago

@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!

addmaths07 commented 11 years ago

Db model needs updation too, many of the references are missing.. I have attached the visual model DB Model

edgewyn commented 11 years ago

Completed in #50