This takes advantage of generics, and generally clears up a lot of
inconsistencies and quality-of-life issues.
Start of db rework: clean up, start generics, improve tests
Write some nice aspirational package docs
Rework and document the db API
Tests still pass, at least...now for everything else
Update all callsites of db functions
Finish converting all callsites
Not too bad actually! Centralizing access into the helpers makes a big
difference.
wtf it works
This resolves that completely nonsensical memory leak situation. As far
as we can understand, the cause was a hodgepodge of the following:
- There is some buffer sharing going on deep in pgx
- Queries made with a cancellable but long-running context (like that
used for background jobs) would leave iterator-related goroutines
hanging
- These goroutines had a pgx `rows` object in their closures, preventing
the row stuff from being garbage collected
- If you look at a profile, it all appears to be caused by whatever
functions were doing the most database queries / reading the most from
Postgres. In fact those things were _allocating_ the most but not
retaining any of that data - it was being retained by these other
goroutines because of magic buffer sharing huzzah I love it
We could have solved this in approximately 30 minutes if Go could
actually tell us what is keeping things alive in the heap, instead of
just tracking allocations.
This includes the ability to "shadowban" new users who have not yet been
approved. We do not have UI for approving these users.
Migrate deserving users to new Approved status
Add post fetching helpers as well
The logic in the thread/post stuff is definitely getting redundant, but
I'm not sure I'm yet ready to try to abstract any of it away.
The next thing to do is probably to update blogs and other places that
fetch threads/posts, and delete the old helpers.
Move forums and blogs fully to new helpers
Use the helpers on the landing page too
that was easy!
Fix up some spots I missed
Check user status and use helpers on the profile page
Threads can stand alone now. Threads can be attached to resources
directly without requiring a category. In addition, a lot of wiki stuff
and library discussion stuff was deleted because we're not gonna port
it.
I am in the middle of:
- porting the landing page
- making some db changes to help with that
- deleting the member and memberextended tables
Mainly the last one. Doing so requires us to update all the other tables
that currently point at member and memberextended so that the foreign
keys will point directly to users. The big thing that we still have yet
to do is links, and actually copying data from the member and
memberextended tables to users.
Ben Visness
Asaf Gartner