Migrate to SQLModel and improve relationship loading

[kitsuta]

It turned out that upgrading SQLAlchemy, which made all our model properties None before saving to the database, broke our form instantiating logic. Rather than fight with WTForms to accommodate that, I chose to move us to SQLModel to let us set Pydantic default types on models defined for SQLAlchemy. This involved:

• Replacing all backref relationship definitions, which were deprecated in SQLAlchemy and unsupported in SQLModel, with explicit relationships
• Reworking our cascade deletes:
  • We were setting the default cascade to delete but only on relationships not defined by backref, which meant that half of our relationships were NOT doing cascade deletes by default. Now that all relationships are explicit, the better default is save-update/merge/etc, with cascade deletes defined manually
  • The SQLAlchemy docs recommend configuring cascade deletes at the foreign key level for the DB and at the SQLAlchemy level, but we weren't doing that in most cases. Also added the passive_delete option to support those DB-level cascade deletes
• The uselist property was removed as it's no longer required -- SQLAlchemy is smart enough to see whether we type the relationship property as list[Model] or just a singular Model
• The SQLAlchemy docs recommend pairing single_parent with a unique constraint to enforce one-to-one relationships. The single_parent property has also been removed from any relationship that isn't one-to-one

Separately, an attempt was made to default our relationships to raise loading to prevent excessive lazy loads/N+1 queries. This ultimately didn't pan out because of the enormous scope involved, but I did review all current relationships for places where it was appropriate to do joined loading or selectin loading by default, so we should still see some improvements.

Old description below since it has some to-dos that are worth keeping:

Changes the default relationship loading strategy to raise in order to avoid generating N+1 queries.

We override this default on many relationships at the mapper level to save on needing to do it at the query level. For one, most child objects in many-to-one relationships do one-sided joined eager loading for their parent object. There are some exceptions based on how “important” the parent is to the children (so, e.g., Attendee and Group creators don’t get joined automatically because we rarely use that relationship). Additionally, tables that are very closely tied together or frequently reference each other get joined or selectin loading on both sides of their relationships (joined if it’s a one-to-one or many-to-one, selectin if not).

TODO:

• There’s a lot of relationships, especially surrounding departments/jobs, that are effectively used as query shortcuts. I do not like that and would like to remove them.
• Only a few pages work currently and many queries need to be updated, especially on the Attendee object where we leave raise on most child relationships.
• Related to the above point, I slapped select (which is what we think of as 'lazy loading') on a few relationships just to get things to load. Most of those should be removed, except in a few cases where we're sure it's unlikely to cause problems (e.g., there's no reason to access the PasswordReset relationships in bulk, so it's probably fine to leave it).
• Need to decide what to do with the active_receipt relationship. This relationship IS used frequently (especially on the Attendee object, where we're constantly checking their amount unpaid), but the ModelReceipt, ReceiptTransaction, and ReceiptItem tables are all joined together (for good reason) so eager loading them all every time we touch the attendee seems inappropriate. OTOH, we are probably doing that anyway so it might be best to just add joined to the mapper, at least for now.
• Once we get most queries/most pages working we'll have a good idea of what kinds of queries are the most common and we can pull those out into services, which will be a good opportunity to reorganize the backend file structure.

[bitbyt3r]

Does this need to be called? Shouldn't session already be defined and set to the session by the context manager?

[kitsuta]

Huh, yea, this must have been an old copy-paste error.