Matchu
3744a476e5
Ah okay, pools support `query` and `execute` the same way connection objects do (as a shorthand for acquiring, querying, and releasing), but it doesn't have the same helpers for transactions. Makes sense: you need those queries to go to the same connection, and an API where you just call it against the pool object can't tell that it's part of the same thing! Now, we have our transaction code explicitly acquire a connection to use for the duration of the transaction. An alternative considered would have been to have `connectToDb` acquire a connection, and then release it at the end of the GraphQL request. That would have made app code simpler, but added a lot of additional potential surprise failure points to the infra imo (e.g. what if we're misunderstanding the GraphQL codepath and the connection never gets released? whereas here it's relatively easy to audit that there's a `finally` in the right spot.) |
||
|---|---|---|
| .. | ||
| AppearanceLayer.js | ||
| ClosetList.js | ||
| Item.js | ||
| MutationsForSupport.js | ||
| Outfit.js | ||
| Pet.js | ||
| PetAppearance.js | ||
| User.js | ||
| Zone.js | ||