Suggestion: Add the series ID to every chapter update in the API
Because JNC does not provide notification and watch list by default, I have been using my own tracker to follow series. First, let's look at an entry for a series:
And an update entry:
There is one very big problem with the API: there is nothing to indicate whether an update belongs to which series. The only way I can know is to manually gather that "name" part in every update entry and assign those names to a list of series, like this:
And the worst: sometimes those "names" change between volume, so my filter will miss new updates until I browse the forum and realize "dang, there are new updates for that series" (as I'm writing this I have missed some updates of Elf Bride manga since it was changed from "Elf Bride manga" to "Elf Bride (Manga)").
And the icing on the cake is that I need to remove the volume number after those names. It can be quite random, like Arifureta 1, Arifureta V1, Arifureta Vol.1 or Arifureta Volume 1; and this can change even more frequently. I need to use a hacky function to strip it:
(If Yuri Vampire gets a second volume called Yuri Vampire 2, that function will be dead)
TL;DR: please add an ID that is unique to each series to their respective updates. I think it won't break any existing thing.
@tgquan67 Matching linkFragment to parts' and volumes' titleslug is way easier than guessing using title. Although you'll need to request parts and volumes for that to work.
I think it's not hard linked to anything so they can create event for a yet non-existing entity so it probably won't change.
@_08 hmm I haven't tried that yet, will test it this weekend.
And since this is using mongo, it doesn't even need to be a pre-defined column. Just include something like source_id when applicable.
If you're trying to follow series, that implies you want to know when new parts are released. Why, then, are you pulling the speculative release dates from the schedule list, which just has estimated dates (the parts could be released before or after that date)? You can get a list of parts that have actually been released (so that you can then highlight new releases) from the series API. That gets you the series and volume IDs that the parts belong to.
Here's what the JNC site actually requests:
You could probably exclude volumes if you just care about prepubs, and you could probably replace the where clause with the series ID if you wanted.
@_08 okay, I tried matching titleslug to linkFragment, and in short, it also has the same problems as matching titles:
- Some series have overlapping titleslug, for example how-a-realist-hero-rebuilt-the-kingdom and how-a-realist-hero-rebuilt-the-kingdom-manga. That makes finding the correct titleslug in all linkFragment impossible (anything matches the second also matches the first).
- If I cannot assume that the linkFragment is in the format /?/titleslug-volume-?-part-?. Trying to clean that linkFragment will lead to a more complex function than what I'm using to clean the title. Some example:
Some series have overlapping titleslug, for example how-a-realist-hero-rebuilt-the-kingdom and how-a-realist-hero-rebuilt-the-kingdom-manga. That makes finding the correct titleslug in all linkFragment impossible (anything matches the second also matches the first).
You'll be looking for how-a-realist-hero-rebuilt-the-kingdom-volume-10-part-1 and how-a-realist-hero-rebuilt-the-kingdom-manga-volume-2-chapter-6 and closest the closest matches (if you consider longest common prefix to be closest which is the most simple way to do it) would be how-a-realist-hero-rebuilt-the-kingdom-volume-9-part-1 and how-a-realist-hero-rebuilt-the-kingdom-manga-volume-2-chapter-5 respectively. Also, events are properly tagged as manga/novel, so you can use that to avoid confusion between the two.
As fucked up as it sounds, I was also matching them using thumbnails at some point.
you forgot /c/ascendance-of-a-bookworm and Okada's autobio. Luckily, those particularly problematic cases (and most of first parts) are normally uploaded at the same time as event is added so you can have an exact match.
@_08 well, ideally I want that with each update event I can compare it with a "watching list" and decide right away whether it matches or not; instead of comparing it to every title available to decide the exact title, and only then check if the title is in our "watching list". The complexity isn't affected much though (number of watching titles x number of event VS number of titles available x number of event).