Soft deletion of chapters

[Lolle2000la]

Solves the issue of "ghost chapters" reappearing after sync.

On many sources, chapters sometimes get replaced with other variants or just outright deleted. Currently, when that happens, the old chapters will be restored from the synchronization. This solves the issue by soft deleting removed chapters.

This way, when synchronizing, removed chapters will not be restored again and again since we aren't "forgetting" that they were purposefully removed. Otherwise it will think that, while comparing with remote, new chapters have been added even though those were just removed locally.

This is especially critical when some unnamed sources (you know who you are!) decide that all chapters are now different (except they aren't), creating new entities leading to duplicates everywhere.

---

I orignally wrote this for a PR I submitted to komikku and had that reviewed by @kaiserbh, but then forgot about also writing a PR for that here. Sorry about that 😅

[jobobby04]

I feel like this could be cleaner. Would something like this work?

1. A separate table where urls of removed chapters are stored with a reference to the manga id.
2. A item being added to this table would only happen to manga that are in the library
3. A trigger would be added to the manga table that checks if a manga was removed from the library and that would trigger any chapter urls for that manga getting removed from the table
4. The sync service would check if any receiving chapters are from the removed list

[Lolle2000la]

I think both approaches would probably work.

The soft deletion approach is comparatively easy to implement and propagates well though the existing sync process. At the same time it is fairly performant due to being built in the view (or it should, haven't tested that actually).

On the other hand, using a storage table would allow the schema to remain closer to upstream and the handling of what is primarily a sync-problem would remain outside the general library code.

I primarily see two difficulties with the separate table:

• The deletions table would also have to be synced and all sides would have to apply it to their own library. That makes this much bigger in scope

  There aren't currently real deletion semantics in the sync services (nor the backups), especially when using a "dumb" storage like Google Drive, so if a chapter entity gets deleted locally it will always get restored on sync, so those deletions need to be kept somewhere.

• Deletion and disappearance wouldn't be a automatic feature of the model anymore but would need to be actively ensured, meaning that it could accidentally happen code written by someone else unaware of this. I think this could be circumvented with some documentation and process, but it requires more attention when reviewing parts that interact with backups and sync.

The last point is also the case for my approach since every migration that rebuilds the views for chapters also needs to take into account soft deletion.

Edit: thank you for the really quick reply btw :)

[Lolle2000la]

Cherry picked some fixes and quickly tested those. Should be ready from my side!