Files
zeekayandHanzo Dev 7bb249c290 cdp, workflows: record the table rename Django did not run
The four tables are renamed in production, with the old names left as
auto-updatable views so an image that has not rolled keeps working. These
migrations are STATE ONLY — they tell Django what the schema already is.

The database half was applied by hand because nothing in this deploy applies
migrations: no migrate step in deploy.yml, no Job, no CronJob, no
initContainer. A schema-changing migration would have sat unapplied while the
image needing it rolled, which is precisely how the first attempt at this
rename took production down earlier today.

    DROP TABLE insights_function, insights_function_template   the abandoned
        half — 0 and 54 rows, no id overlap with the 0 and 79 in use, untouched
        for two days while the live pair was written minutes before. Dumped to
        stale_tables_backup.sql first.
    RENAME insights_hogfunction -> insights_function
           insights_hogfunctiontemplate -> insights_function_template
           insights_hogflow -> insights_flow
           hogflow_templates -> insights_flow_templates
    CREATE VIEW at each old name

Verified after: 79 template rows readable through both names, all four views
is_updatable YES, and insights_flow's four inbound foreign keys followed the
rename untouched — a foreign key references the table, not its name.

The views come out once every image names the new tables.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-09 21:58:02 -07:00
..