Fix library/category count mismatch from duplicate category-manga rows - #2247
Open
Seanstoppable wants to merge 1 commit into
Open
Fix library/category count mismatch from duplicate category-manga rows#2247Seanstoppable wants to merge 1 commit into
Seanstoppable wants to merge 1 commit into
Conversation
Add a unique constraint on CategoryManga(manga, category) via migration M0061, deduping any existing duplicate rows first. This was the root cause of library/category counts not matching the number of manga actually selectable: duplicate rows inflated Category.getCategorySize() plain row count while getCategoryMangaList() grouped by manga and collapsed duplicates. Harden the insert paths against races using Exposed's native upsert/ batchUpsert (MERGE/ON CONFLICT), keyed on the (manga, category) unique constraint, instead of insertIgnore (unsupported by H2 outside MySQL mode) or manual try/catch retry loops. Add regression tests proving the unique constraint is enforced and that adding a manga to the same category twice is idempotent.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Library/category counts didn't match the number of manga actually selectable in that category, worsening as manga were moved between categories.
CategoryMangaTable(the manga<->category join table) had no unique constraint on(manga, category), so racing check-then-insert code paths could create duplicate rows.Category.getCategorySize()does a plain row count (inflated by duplicates), whileCategoryManga.getCategoryMangaList()groups by manga columns (duplicates collapse) - hence the mismatch between the displayed count and what you could actually select.What changed
M0061_PreventDuplicatedCategoryManga: dedupes any existing duplicate(manga, category)rows, then adds aUNIQUE (manga, category)constraint. This is the core fix - counts are now correct by construction.Library.addMangaToLibrary,CategoryManga.addMangasToCategories) against the underlying race using Exposed's nativeupsert/batchUpsert(compiles toMERGE/ON CONFLICT), keyed on the(manga, category)constraint. This gives real "insert if not exists" semantics on both H2 and PostgreSQL without relying oninsertIgnore(unsupported by H2 outside MySQL compatibility mode, which this project doesn't use) or manual exception-driven retry logic.Note: a manga can still belong to many different categories - the constraint only prevents the same manga+category pair from being duplicated.