radiator
radiator copied to clipboard
podlove
Set basic data structure (station, podcast, episode)
RFC
There exists a station as the root-node for all podcast related data (initially set). You can't delete this station (only rename it), but you can add additional stations that can be deleted. (example: metaebene is a station)
Every station can has multiple podcasts. each station has at least one podcast (initially set for every created station) You can add more podcasts and delete all but the last one.
Every podcast has at least one episode that isn't published and in some kind of wip-status. if you publish an episode a new wip-episode will be created automatically.
(1-n) Station => (1-n) Podcasts => (1-n) Episode
Hey @lukad & @electronicbites,
could you please have a look at the idea for structuring data? Maybe we could have a quick discussion about this?
Since we have identified very variable definitions of items I would like to stay as flexible as possible at least in the beginning until we gathered some experience. We are probably dealing with a tree structure building the outliner. So every leaf in the tree has a type, a parent node, a public uuid, a priority, an owner and a type dependent list of attributes. We could start with a flexible Json structure as an attribute of the item but we might end with an extra table for these, e.g. URLItem or likely. This will depend on what we are doing with them. Should URLs be stored only once and be reused for instance?
But the tree consists of generic items, so we can add URLs to an episode or a chapter (correct name?) of an episode.
For podcasts I would suggest a state-machine. It has different states and transitions (e.g. publish).
After a second thought I am not too sure about this anymore. How many states do we have? Are there only two? If thats the case a state-machine doesn´t make sense.
@electronicbites, I think having a seperate table for each item type is the way to go in terms of maintainability and db operations. An item would have a type/kind set to url + url_item_id.
State machine per might be a good idea, I can think of at least one other state which would be something like on-air, although that would be on an episode basis.
I don't really understand the reason for always having a "wip" episode. Why not just create it when it's needed?
