Manga List Bug Topic

2 years ago
Posts: 3
This page is bugged: https://www.mangaupdates.com/series/c6p8t9a/joujuu-senjin-mushibugyo

2 years ago
Posts: 10866
Quote from Deago
This page is bugged: https://www.mangaupdates.com/series/c6p8t9a/joujuu-senjin-mushibugyo
Fixed now
A just ruler amongst tyrants

2 years ago
Posts: 35
Duplicates - 2nd one is mostly empty
https://www.mangaupdates.com/series/dcruikd
https://www.mangaupdates.com/series/yrfxvbw/24-jikan-osoware-jigoku-gorieki-wa-shojo-soushitsu

2 years ago
Posts: 10866
Got rid of 2nd
A just ruler amongst tyrants
2 years ago
Posts: 35

2 years ago
Posts: 10866
Quote from goruu
Chapter 18a should be chapter 8.
Fixed
A just ruler amongst tyrants
2 years ago
Posts: 4
Fate/Grand Order: Epic of Remnant - Shinkai Dennou Rakudo SE.RA.PH is on chap 29 not 39

2 years ago
Posts: 10866
Quote from Komic
Fate/Grand Order: Epic of Remnant - Shinkai Dennou Rakudo SE.RA.PH is on chap 29 not 39
Fixed
A just ruler amongst tyrants
2 years ago
Posts: 137
the 'list option' filter in advanced find is not working when I specifically select one of my custom lists
2 years ago
Posts: 10
"Only show manga not on any of my lists" not working. I have mangas in my completed list and i have selected to not show any items from my list in the advanced search, but its showing anyway. It even shows the indicator that its in a list when i search. It shouldnt show them, but it does.

2 years ago
Posts: 2852
If you have more than a certain amount of items in your list, then it will stop working. It only works for 10,000 I think.
2 years ago
Posts: 10
Why tho. If i would build a sql query i would just join the tables and filter it out if its exist. Something like that 'SELECT table1.*FROM table1 LEFT JOIN table2 ON table1.id = table2.table1_id and table2.user_id = 1 WHERE table2.table1_id IS NULL;'. I doubt that this will take much longer than the normal query without that when the tables are linked with foreign keys. I dont even know how to add a limit of 10k. (Assuming you have a table structure like this for the lists: id int, list_id int, user_id int, table1_id int)
EDIT: and there seems to be another problem with the functionality of it. When i add something to a list on a new account with no lists it takes a few minutes before it works. That could be a caching issue.
EDIT2: now that i think about it. the performance will be worse. the line row lookups should double compared to the normal search, since it needs to lookup a single row in table2 for each row that is processed in table1. But this is inevitable when processing lists. even if there is a list that has 1mil mangas in it it should query all of them within a few ms. Assuming were just reading the 2 ids that is 32byte each. This would be a total of 64mb that would need to be processed(1million rows is quite exagerated compared to normal requests). I dont even know if its parsing the ids when its linked with foreign keys
2 years ago
Posts: 6
Onna Dakara to Party wo Tsuihou Sareta no de Densetsu no Majo to Saikyou tag wo Kumimashita's latest chapter should be 25c, not 26c.

2 years ago
Posts: 10866
Quote from blackmage678
Onna Dakara to Party wo Tsuihou Sareta no de Densetsu no Majo to Saikyou tag wo Kumimashita's latest chapter should be 25c, not 26c.
Fixed
A just ruler amongst tyrants
2 years ago
Posts: 10
As explained in the last response it does not bring a real performance benefit and it's highly unlikely that there will be many requests anyway since it's a rare occurrence. I can't explain it to myself how exactly you programmed it. If you join it in a subquery and limit the join to 10k or if you doing it in the programming language without sql. The latter is definitely a horrible solution that would be very slow(even if it's go or some other low level language).With a limit of 10k it will introduce some wheird behavior. It should rather return nothing instead of everything when 10k is reached. How does it behave when I have an advanced search for many tags and it shouldn't show in any list. The processed rows will be more than 10k. What if you have a list with 9k entries. Querying by ids is way more performant than string matching, so there won't be a perforce loss
Will you remove the limit?