Remove old squashed migrations

[brianhelba]

We should at least wait until production servers are stable to merge this.

[waxlamp]

I've never understood the rationale for squashing migrations. Other frameworks (like SQLAlchemy?) do it as a matter of course, IIUC, so there must be a good reason for it. To me it's a sort of lossy compression so there's some value in keeping it around (to detail the history of migrations). I'm curious what the downside is.

[brianhelba]

One benefit is test performance: each time the tests are run, since a fresh database is used, all migrations must be applied fresh. This isn't typically too big of a performance cost, but eventually it adds up if numerous intermediate tables / columns / constraints need to be created and destroyed just to get to the end state.

This PR was more motivated by the fact that many old the old migrations had names which violated Python naming guidelines (they contained -, instead of only _). Also, some of the now-elided migrations contained raw SQL which was triggering security warnings.

[brianhelba]

Now that #1777 has been applied to production, this should be safe to merge.

@danlamanna Can you confirm?

[brianhelba]

@danlamanna just confirmed it.

[dandibot]

🚀 PR was released in v0.3.68 🚀

[aaronkanzer]

One benefit is test performance: each time the tests are run, since a fresh database is used, all migrations must be applied fresh. This isn't typically too big of a performance cost, but eventually it adds up if numerous intermediate tables / columns / constraints need to be created and destroyed just to get to the end state.

This PR was more motivated by the fact that many old the old migrations had names which violated Python naming guidelines (they contained -, instead of only _). Also, some of the now-elided migrations contained raw SQL which was triggering security warnings.

Hi @waxlamp and @brianhelba -- just wanted to follow up here....

Squashing of migrations in dandi-archive is bit tricky now for us in linc-archive land, as we rountinely sync our fork with dandi-archive, thus we are susceptible to changes downstream -- e.g. squashing of migrations with not much consultation or planning is disruptive to any linc-archive re-deploys. Furthermore, any changes outside of the routinely automatic Django migrations workflow presents risk.

Also, @brianhelba, in regards to performance bottlenecks in testing, even with limited migrations, I'd encourage the usage of the --reuse-db flag, as it is intended to specifically resolve your pain point here. pytest also provides additional mechanisms to use parallelism/speed up test suites.

I think I'd like to have a larger discussion here (perhaps Dandi standup would be the right forum) for how we navigate over-arching changes in dandi-archive moving forward, as ideally more apps will inherit functionality (linc-archive and hopefully other scientific initiatives) and the intricacies that come with such functionality -- let me know your thoughts.

Cc @kabilar @satra