-
- Some agile planning for the next few tickets.
- Remember that alembic is a migration tool. It’s meant only for database revisions. Changes to the schema.
- I somewhat abuse this for data changes as well. But I only really want this as a record of larger data changes: backfills, important deletions/additions, etc.
- If starting over, I would probably just keep a separate directory for
migrations/scripts
alongside migrations/versions
. Just like stored procedures.
- I’ll try to start doing that now. It could be sql that I pass to a DO command. Or a python script that uses sqlalchemy (probably easier, since I have access to the app’s helper queries/commits, and more consistent with the migrations).
- Yup, I ended up doing this. Added notes to
ADMIN.md
and created the migrations/data_changes
folder with an example python script.
- Subscribed to PR notifications in the
graphql-sqlalchemy
repo to check specifically when sa2 support is merged: https://github.com/graphql-python/graphene-sqlalchemy/pull/368. I don’t think you can subscribe to single PRs only.
- Bought another ember mug – my current one is 2 years old and is very finicky when starting/stopping/charging. The new one is white/14oz vs the old black/10oz.
- The 3 rise garden nutrients were Sprout, Thrive, and Blossom. You’d add sprout at the beginning, blossom and the end, and thrive throughout all stages. Thrive is a micronutrient blend. Sprout and blossom are macronutrient blends. In the new dry nutrient blends, they combined thrive into both sprout and blossom! So you only add sprout at the beginning (optimized for stems/leaves) and blossom at the end (optimized for fruits/flowers). And you only need to order two thirds as much, so 66% the costs. And they balanced the dry nutrients better for overall health as well as ph, so plants will grow slightly faster/fuller. All around win.
- SBSC. New
teams
and statuses
tables.
- https://gitlab.com/bmahlstedt/supercontest/-/issues/175
- Fixed all the sequences, their data types, and start values in postgres.
- Added col defaults for all PK ID cols for my 8 tables in pg, set obviously to nextval of the corresponding sequences. 3 of the tables were missing this! Then I can remove it from models, where the sequences were explicitly defined in the ORM layer (saving my butt for those 3). Better to push this to the data layer.
- Sqlalchemy will create the
<table_name>_id_seq
and column_default
automatically for ID PK INT cols.
- Also note – this is all because I didn’t really know what I was doing when creating the tables originally.
- Some detail (a very good general reference for postgres sequence management) as well as explicit commands on this comment: https://gitlab.com/bmahlstedt/supercontest/-/issues/175#note_1292435219
- Read through a bit of the alembic documentation. Remember to do
alembic.op
for the database interactions. You can use sqlalchemy
for stuff like datatypes eg sa.Column('id', sa.Integer())
. Try not to use db
from the supercontest – that’s the flask scoped session manager.
- Another bit of canon: No dependencies on your app within the migrations. It should only depend on the database. This means some convenience queries/commits/utils from your app are unavailable. You don’t have to follow this perfectly. You can use sqlalchemy to bind to the same alembic key and send ORM queries. Or you can use
op.execute
to run a select
and use those results, if you want to stay 100% in the SQL layer.
- Went through and rewrote the season rollover migration to be a lot cleaner.
- Made the
admin.add_view()
for all AdminModelView
models dynamic. It inspects the non-FK cols in a table and makes those cols searchable in the admin panel. I was manually maintaining those (breaking often), and copy-pasta of the longer add_view
calls. Much cleaner now.