You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, was looking to work through a few of the items on the to-do list on PR #569 and looking at enriching the item details page, had a design suggestion for handling extended attributes and per-item type specific information. For example, TV shows often have an attribute called "Network", but that's a bit superfluous for movies, games and books. Similarly, games could use a "Publisher" attribute which also works for books, but not so much for TV/movie. And books could use an "Edition", but that's not as useful for video content.
To get to the point, I'm not seeing a good case to keep extending the MediaItem table with adhoc attributes which really only belong to specific item types. There are a few in there already, so these could also be moved to simplify that table a bit more too.
I'm suggesting a simple MediaItemAttributes lookup style table with the primary key being MediaItemId and AttributeName to look up an AttributeValue (perhaps with an update timestamp too). Then there is no specific limit to which attributes can be stored and extending to keep other/new attributes is simpler. Plausibly, this also needs an AttributeType to group them, but that could also just be an internal config table so the AttributeName could just be an id instead.
The table would look something like this where MediaItem with ID=1 is the TV Show "1923":
MediaItemId
AttributeName
AttributeValue
SortOrder
LastUpdated
1
Network
Paramount+
1
2024-12-12
1
Created By
Taylor Sheridan
2
2024-12-12
1
In Production
true
3
2024-12-12
1
Status
Returning Series
4
2024-12-12
The benefit of this approach is that you don't need to pick which attributes to show (or not), you just select from the attributes table and display the results.
There's a helluva lot of information that comes over some of these upstream API's, it's a shame to not capture & use more of it.
The text was updated successfully, but these errors were encountered:
So, was looking to work through a few of the items on the to-do list on PR #569 and looking at enriching the item details page, had a design suggestion for handling extended attributes and per-item type specific information. For example, TV shows often have an attribute called "Network", but that's a bit superfluous for movies, games and books. Similarly, games could use a "Publisher" attribute which also works for books, but not so much for TV/movie. And books could use an "Edition", but that's not as useful for video content.
To get to the point, I'm not seeing a good case to keep extending the MediaItem table with adhoc attributes which really only belong to specific item types. There are a few in there already, so these could also be moved to simplify that table a bit more too.
I'm suggesting a simple MediaItemAttributes lookup style table with the primary key being MediaItemId and AttributeName to look up an AttributeValue (perhaps with an update timestamp too). Then there is no specific limit to which attributes can be stored and extending to keep other/new attributes is simpler. Plausibly, this also needs an AttributeType to group them, but that could also just be an internal config table so the AttributeName could just be an id instead.
The table would look something like this where MediaItem with ID=1 is the TV Show "1923":
The benefit of this approach is that you don't need to pick which attributes to show (or not), you just select from the attributes table and display the results.
There's a helluva lot of information that comes over some of these upstream API's, it's a shame to not capture & use more of it.
The text was updated successfully, but these errors were encountered: