mirror of
https://github.com/hanzoai/insights.git
synced 2026-10-30 16:15:31 +00:00
zeekayandHanzo Dev
e1c6e1315b
Postgres names a table's own constraints after it at creation and never revisits them, so every table renamed out of the mascot kept a full set spelling the old one: 14 indexes and 40 constraints, counted against the live database. Nine of those are the review app's, and they were a real drift rather than a cosmetic one -- models.py has said review_ since the app was renamed, so makemigrations wanted to drop nine indexes and build nine more. It now renames them, which is what was meant. The rest Django does not track at all: it derives a primary key and a NOT NULL from the column, and the check constraint comes with PositiveSmallIntegerField. Those move on the database side alone, and they move to the name Postgres would generate for the table today. Each rename is written as a loop over the catalogue rather than as a list of statements, because the statements would only be right for a database in one particular state. The loop is right for three: one already renamed, one never named that way because it was built after the tables were, and one waiting for this. Applied to production ahead of the deploy and verified there: zero indexes and zero constraints left carrying the name, every statement re-run a second time without error, and the planner picking the renamed indexes by their new names. Co-authored-by: Hanzo Dev <[email protected]>