"Show user's posts" filter shows other posts, rewrites thread in DB

[baka-kaba]

Ok, I've found out why you sometimes get a bunch of random posts following a specific user's posts, and it ain't pretty

What basically happens is:

• the call goes to the site for a specific user's posts in the current thread
• the site returns a new 'version' of the thread, only containing that user's posts
• we parse the first page of that thread, scraping all the metadata - total number of pages, number of posts on the page, etc
• this rewrites the thread metadata - now it looks like the thread has shrunk, the number of read/unread posts changes, a massive thread can become a 2-page one and the entry in the thread list reflects all this
• then the page is handed over to the post parser - because it thinks this is page 1, it starts overwriting the post entries in the page 1 index range. The same happens if you go to page 2 of the filtered thread, and so on

The upshot is the start of the thread basically gets rewritten in the DB, as you view the pages of the filtered version. But because the rest of the thread's post entries are still in the database, when the thread view comes to display a filtered page, it requests the posts in that page's range - if those posts weren't all overwritten with the filtered ones, the rest will be the original posts for that page, probably by other people

You can test all this by taking a large thread (preferably with an unread count visible), filtering on a user's posts, and then looking back at the thread list - the page and unread counts will have changed, and the last page will probably have other people's posts at the end. You have to view the 'full' thread again to fix it - and if you don't do the 'hit the back button' thing, the unread count will be messed up. The overwritten posts stay that way until you reload that page from the site

---

Anyway I can see why it works this way, because of how the thread display system works - it literally reads pages of posts from the DB, so you have to overwrite them to change what it's displaying. Not easy to fix without rewriting the whole system. I'm trying to change the way the read/unread counts are calculated, but the rest is too strongly tied into the database structure - it needs abstracting

[Sereri]

Can we maybe hack this by making it use a different, virtual thread id? like threadid:123456789_Sereri or something?

e:/ nvm it's integer. Welp

Also Google released some new SQLite mapping libary called Room. This might be worth taking a look at maybe.

[baka-kaba]

Yeah I saw the ORM and it would be great to use it, but the app's so not ready for it! There's so much spaghetti and view stuff talking direct to the database almost, it needs pulling apart. That's what I was trying to do with the Forum package but there's so much hardwired into using int IDs and building making database queries and network requests, it's a ton of work and it's basically a rewrite of a lot of the app

The appended ID is a good idea... since it is sort of another 'thread', and it'll never show up anywhere else (and get purged after a week anyway). Only trouble is the thread ID is an integer in the database, and (of course) everything's pulling rows out of the database and expecting ints from that column. I'm not sure if we can quickly hack this, I'll have a look at it though

I'll push the tweaks I made to the parsing code, hopefully it's a bit easier to follow and it should fix some of the gotchas with reply calculations. There's other fun stuff that needs fixing though (like ignored posts aren't added to the post database at all if 'always ignore' is set in the options)