-
- Genesis filing bankruptcy.
- Private work.
- DePIN = decentralized physical infrastructure networks.
- NBA trade deadline is Feb 9.
- SQLalchemy.
- Remember sqlalchemy relationships. One-one, many-one, one-many are all “back populating” relationships. Just places foreign keys so a column matches another table. Can be unidirectional or bidirectional. The many-many case requires an association table. This can just be a simple table with 2 cols, id FK for the first association and id FK for the second association. Or you can make the logic more complicated.
- These relationships at the ORM level allow you to query on back-populated properties. I can query on
User.leagues in python, for example (in psql you cannot query users.leagues, you’d have to join/query league_user_association).
- Remember to be careful using
op.execute mixed with ORM commands inside of scripts (like alembic migrations). I’m not sure of the exact terminology, but there’s (session, base, flushing?) behavior that’s different between the two. A lot of my core functions use the ORM to query, which won’t pick up immediate results of things like inserts and updates from raw op executions right before.
- You can use
db.session.execute (and then db.session.commit right after) or direct with db.engine.execute which is basically the same as op.execute or psql.
- With an ORM, you don’t insert directly into the association tables. Just update the relationship columns on the main tables and sqlalchemy will insert into the association table as necessary.
- SBSC.
- Added the paid leagues, unique for each season.
- https://gitlab.com/bmahlstedt/supercontest/-/issues/173
- This obviously requires an association table. Note also though; the role table can technically just be an FK, or even an
is_admin col in the users table.
- Piped everything through all views. The frontend now defaults to the paid league (for allpicks, lb, and graph) if you’re in it for that season, or free if not.
