ref: add hard-stop migration for index_together migrations rebase

[asottile-sentry]

I'm going to be "rebasing" the migrations to eliminate index_together such that we can upgrade django (upstream doesn't have a good suggestion on how to do this other than "delete all the migrations and start over" which is pretty messed up)

those PRs look like this: https://github.com/getsentry/sentry/pull/76515 -- I'll essentially be requiring:

• self-hosted has progressed past the last migration that modified index_together
• I'll modify the migrations to make it look like they never had index_together but still resulted in the same state

[asottile-sentry]

Hmm, I'm not sure that we need a hard stop here. This is essentially just a code change and makes no change to the database right?

Can we just generate the migration and mark it all as just state changes?

no, we can't have index_together anywhere in migrations -- even historic ones

[asottile-sentry]

Hmm, I'm not sure that we need a hard stop here. This is essentially just a code change and makes no change to the database right? Can we just generate the migration and mark it all as just state changes?

no, we can't have index_together anywhere in migrations -- even historic ones

django sucks

[wedamija]

Hmm, I'm not sure that we need a hard stop here. This is essentially just a code change and makes no change to the database right? Can we just generate the migration and mark it all as just state changes?

no, we can't have index_together anywhere in migrations -- even historic ones

Why can't we modify the historic migrations to use the new syntax? It still produces the same indexes in postgres right?

[asottile-sentry]

Hmm, I'm not sure that we need a hard stop here. This is essentially just a code change and makes no change to the database right? Can we just generate the migration and mark it all as just state changes?

no, we can't have index_together anywhere in migrations -- even historic ones

Why can't we modify the historic migrations to use the new syntax? It still produces the same indexes in postgres right?

they're not always equivalent because they produce different names (and the index_together name appears to be not deterministic / based on postgres version / based on django version)

[asottile-sentry]

adjusted the hard stop after some testing -- since it wasn't actually requiring that migration to have run!

[asottile-sentry]

@getsentry/owners-migrations how does this look? I'd like to merge this so I can start fixing these

[asottile-sentry]

lgtm. Since we're doing a hard stop, should we also consider including a squash here?

normally I would say yes -- but the process for a squash actually makes it harder to do what I'm trying to do (and the squash itself doesn't help since the actually operations for index_together don't seem to get "optimized" down)