✨ add transaction types and api route helpers

[danyx23]

This PR adds custom types for read only transactions and read/write transactions. Through some typescript magic this is set up so that functions that need a read only transaction (because they only run select statements) can also be given read/write transactions but functions that need read/write transactions do not accept a readonly transaction.

This PR also adds helper functions for API request handlers that also set up a transaction (which means that instead of writing a callback that takes a (request, response) tuple you write one that works with a (request, reqsponse, transaction) tuple).

[danyx23]

• 🚧 remove typeorm annotations from GDocs classes #3299 : 2 dependent PRs (#3358 , #3372 )
• 🐝 remove obsolete code #3298
• 🔨 migrate charts from typeorm to knex #3293
• 🔨 clean up posts access via knex #3292
• ✨ add transaction types and api route helpers #3271 👈
• 🔨 migrate PostLink to knex #3259
• 💄 reorder parameters of knexRaw and knexRawFirst to have knex in first pos #3258
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @danyx23 and the rest of your teammates on Graphite

[danyx23]

I think we should do this once the whole stack is converted to knex. This will be a bit annoying because there are about 250 promises in our codebase that are not explicitly awaited, many of them totally fine (e.g. react event handlers that don't await the result of the handler); but now that we switch to transactions on all api router handlers, failing to await a promise could potentially try to access the database transaction after it has been commited or rolled back. Cases where this happens were an error before already (e.g. errors in these promises would not be reported back) and could be related to #3159 and other similar issues.

[marcelgerber]

Nice, hard work!

What I did as part of this review:

• Went over (pretty much) everything and checked that it makes rough sense
• For apiRouter in particular, checked that we never use a transaction with the wrong kind of permissions
• As a sanity check, I made the RO and RW types incompatible to see all the places where a RW transaction is passed to a method requiring a RO transaction - and all of these places make sense, i.e. the caller actually writes something.

It would be great if we could somehow also remove the .insert, .update etc. methods from the RO transaction altogether, but I don't believe this to be possible given the query builder nature of knex. A man can dream...

[danyx23]

Merge activity

• Mar 26, 10:04 AM EDT: @danyx23 started a stack merge that includes this pull request via Graphite.
• Mar 26, 10:08 AM EDT: Graphite rebased this pull request as part of a merge.
• Mar 26, 10:09 AM EDT: @danyx23 merged this pull request with Graphite.