• To remove from a collection that represents a many-many relationship, just delete that list element and commit. You could also wipe it all by doing something like
• user = db.session.query(User).filter(x).one()
• user.leagues = []
• db.session.commit()
• I docker-compose downed the 3 bmahlstedt.com containers on the droplet so the supercontest can have the full resources of that tiny machine. I'll move bmahlstedt.com elsewhere. I'll have to remember to bring it back up for interviews, etc.
• Cooked the soaked garbanzo beans. Scalded my hip by splashing boiling water directly on it. Was bad. Blistered up and got all oozy.
• Bought bulk charcoal on amazon. Wasn't prime shipping, but it was $45 for 4x18lbs. Briquettes for $1/lb is usually a good deal - this is half that.
• Big fresh order. $75. Should be good until tough mudder tahoe trip.
• I should tweet this:
• "[B*tches] aint leavin til 6 in the morning" - Snoop Dogg, Gin and Juice
• "Parties dont stop til 8 in the morning" - Jermaine Dupri, Welcome to Atlanta
• what kind of latenights are these rappers getting into
• SQLAlchemy obviously does a join for all relationships. For many-one, it creates a member and for many-many it creates a collection. You can filter against these directly through the ORM, which is nice.
• Use has() for member (many-one), like .filter(League.season.has(season=X))
• Use any() for collection (many-many), like .filter(League.users.any(email=X))
• HAS and ANY are called column comparators. There are a bunch: https://docs.sqlalchemy.org/en/13/orm/internals.html#sqlalchemy.orm.properties.ColumnProperty.Comparator.
• Went to costco to buy beef ribs.
• Interesting, but not surprising. Finishes get more likely as you go up in weight class: 
• 
• Supercontest.
• The league change alone was very simple. I only had to pass the league ID to like 5 places, and then add it as a filter to like 3 queries. This is due to the efficient layering of the query structure.
• Confirmed in the league deploy that the flask monitoring dashboard data persists across versions now.
• I could theoretically remove the entire dbsession.joins module now and just query on the backref relationships, but it's slower. The eager joins are much faster than going through the orm for everything.
• Made it so that if a user is in a non-free league for the requested season, the default is to display that. If you're only in free, it shows free.
• Adding coverer to the Score table, collocated as closely as possible to the information that it depends upon - this makes more sense than putting it in the Line table. There's also no real reason that it needs its own table, it's not distinct enough. It will update in realtime, not waiting until the game is finished. This is because some views want to update colors before the games are finished, but other views want to hold info until status=F/FO (like the lb). The information is there, you can do either.
• All of the same logic above for coverer in the score table is repeated for points in the pick table.
• is_league_in_season should return True if every checked for the free league. Fixed.
• Did the usual efficiency optimization. Looked at FDT, removed unnecessary queries, consolidated others. Saved a ton of time, benchmarks are back down.
• Renamed season_week_blueprint to data_blueprint.
• Today was pretty dumb. Reverted a lot of the changes. Overall, pretty underwhelmed by the inability to nest blueprints, conditionally handle values, set up url defaults, preprocess, etc. Sharing app state to build urls for navlinks should not be this hard.
• Ended up using flask-caching to just memoize the calls that were repeated, rather than solving the problem directly in application logic.
• I have it configured to SimpleCache, which is just a python dict with key/values. Not the most thread safe, but should be fine.
• Checked the FDT profiler to see if not just any sqlalchemy queries were being repeated, but python functions as well. Sorted by cumulative time, then calls, to make sure that nothing from my dist (supercontest.*) was being called a lot and taking a lot of time.