move volume metadata to manga/a separate entity

[Valle_reading_manga]

Somewhat related to this suggestion

I think moving volume data either to the manga or an entirely new entity would have several benefits, some of them listed in the above suggestion.
What volume data am I thinking of?

• chapter range per volume
• volume titles (with future localisation option)
• Potentially even more info, like date of publication, per volume synopsis, or if there were different persons involved in the making of different volumes (think artist(s) changing over time...), ...; although that information would probably be hard to display with the current UI.
  In any case, it would allow for a more structured and extensible way to store volume information than is currently the case.

Data could already be filled in advance (even without uploads), preventing "data loss" (or additional work) when old titles/volumes are delisted.
The chapter range per volume could either serve as preset for "normal" titles or as a suggestion/be entirely disabled for "unconventional" titles.
Additionally, this might even offer some storage savings, storing the relevant data once instead of duplicating it across all 10 versions of chapters in different languages times the chapters per volume - although some ("abnormal") chapters including a volume number but most ("normal" ones) not would probably come with its challenges...

Volume titles is probably pretty self-explanatory, you can sometimes find them clogging up descriptions but at the same time they're nice to have. Why be limited to chapter titles only...

 

[Teasday]

Considering we're not storing any information about volumes at all currently, it'd certainly be more structured. There's absolutely no way converting millions of 1-2 character fields in chapter data to UUID foreign keys is actually going to lead to storage savings though, and it's going to complicate the frontend as we're going to need to start generating volume entries.

What kind of volumes even have separate titles? Some kinda anthology stuff? Webtoon seasons?

 

[Valle_reading_manga]

There's absolutely no way converting millions of 1-2 character fields in chapter data to UUID foreign keys is actually going to lead to storage savings though

Well admittedly that was me being naive, but I was thinking about moving the volume data as a map of chapter numbers: volume id to the title. Meaning you'd get a chapter's volume number going via the title. This'd probably create more problems than it'd solve though.

Spoiler: why did this become such a rant

In any case, since I'm no MD dev you can ignore my blabbering regarding the implementation details...
The intention of this suggestion is getting separate entities for volumes. As for how that's done, I'd trust the devs to be the most capable to come up with the optimal solution. Not that taking into account dev feedback or asking for input would hurt but I won't claim to be more knowledgeable than the devs...

What kind of volumes even have separate titles? Some kinda anthology stuff? Webtoon seasons?

Uh Bartender (and probably many other) has per volume titles (or rather subtitles). But having them in the synopsis isn't where I'd intuitively look for them.

and it's going to complicate the frontend as we're going to need to start generating volume entries.

Yeah, unfortunately I can totally see this leading to a bunch of work. But at least in the mid-longterm, it'd be a useful addition imo...

 

[Teasday]

This seems like such a niche application that I really don't see this happening anytime soon, if ever. It's massive extra complexity in terms of entity relationships (which are already a huge problem) all across the board, all for the benefit of, what, a handful of titles that happen to give subtitles to their volumes? Staff changing between volumes isn't that common or so important that they can't just be listed in the title authors either.

 

[Valle_reading_manga]

Hm, that'd be a shame. Having separate volume entities would be nice if only to allow querying chapters by volume number. And while I agree that both volume (sub)titles and per volume staff are rather niche uses, I'm sure folks smarter than me would come up with better ideas once the foundations have been laid (I understand that you'd prioritise more fleshed out things tho).
In any case, I didn't expect this to get implemented tomorrow, so I'll just hope it'll happen eventually and be happy if it does. Thanks for the response though.

 

[RogueKitsune]

allow querying chapters by volume number.

I am pretty sure the 'GET /chapter' API endpoint already supports that. The frontend just doesn't use it as there probably isn't a good use for it.

 

[Valle_reading_manga]

I am pretty sure the 'GET /chapter' API endpoint already supports that. The frontend just doesn't use it as there probably isn't a good use for it.

Oh you're right nvm that then.

 

[Valle_reading_manga]

This only just occurred to me now, but maybe I should've stated my initial reasoning that led to the idea:
I was mainly looking for what the /aggregate endpoint/index button already offers: a way to get a title's TOC, except it's only useful when a title has enough chapters.
That's why I started to think of alternate ways to get this data and the idea leading to this thread was born (or well, expanded upon from the linked thread since I realised you could store more volume-related information).
Maybe the TOC could be populated using placeholder chapters or some other means without requiring separate volume information...