Current auto-true-delete implementation in dev branch will mark new chapters as read in certain situations
Background
In my mind, the auto-true-delete feature has a few use cases:
- If a chapter is saved or bookmarked, don't auto-delete the chapter regardless of the following
- When one or more chapters are removed and no chapters are added, delete those chapters
- When one or more chapters are removed and one or more chapters are added, delete the removed chapters and add the new chapters as unread
- When a chapter is changed (title, link, text, etc), update the chapter while respecting the read/unread state
These use cases are, more or less, in priority order. If a given implementation solves for a particular use case but fails on previous use cases, IMO it shouldn't be used.
The Issue
val matchingChapter = dbChapters.find { it.url == newChapter.link }
?: dbChapters.find { it.order == newChapter.order }
The issue is, in my understanding, the current implementation (ChaptersDao.kt line 99ish) solves use case 4 while failing on 3 - if a new chapter comes in (so it has a link that does not match existing links), and some chapters were deleted (so the order number of the new chapter matches that of a current chapter that may have been read), the new chapter will inherit the read state of the "current" (not actually matching) chapter. This will I believe always be true if we try to match on order number, so I don't think we should go down that road.
Proposed Solution
What I think we should do is parse chapter IDs for the sources that provide it. This would at least solve for RoyalRoad, which I believe (and could easily be wrong here) is the primary offender for deleting chapters. Some sources may not provide chapter IDs, in which case we could fall back on link or title, but we still shouldn't fall back on order number for the reasons above.
Open Questions
Is there a reason Novel/Chapter ID aren't parsed at the moment? Is that a thing I'm free to implement, or is there something that would screw up?