Allow squashmigrations to create a fresh set of migrations and delete the old ones

[Pascal Briet]

Here is a suggestion : instead of trying to merge together migrations, start from the models.
It would be a sort of equivalent of applying ./manage.py makemigrations on a project with no migrations.

I reproduced this in a script, and it's working like a charm :

• List all the migrations for every app
• Remove the migration files
• Run makemigrations
• Put a "replaces = [(...)]" statement in each one
• Rename them to avoid conflicts.

See script attached. It is surely not the way you would implement it directly in Django, but it might help.

The idea behind it is : not struggling anymore with squashmigrations. Get something clean, and forget about the past.

[Aymeric Augustin]

The downside of this approach is that it loses anything not automatically generated by makemigrations: custom indexes, views backing managed models, etc. — also data migrations but this is rarely an issue in practice. I'm uncomfortable about making it so easy to make the database schema created by migrations diverge from the production database schema.

[Pascal Briet]

I understand your point of view.

This is why this command would be a kind of "--hard" option (when you use this argument with git reset, you know you should be careful :) )
Or anything like it.

Anyway, I will personally use it on a rather big project instead of squashmigrations, and I thought that other people may be interested.

Thanks,

[Pascal Briet]

If we think longer term, would it be suitable to have more about the SQL structure within the models.py files?

We currently consider - my team and I - that models.py is describing the whole database structure (as we don't need yet views or custom indexes).

May it be a good idea to introduce more concepts in models.py files. e.g. for views, having somethink like this :

class MySqlView(models.SqlView):
     QUERY = "SELECT * FROM xxx JOIN yyy ON ...."

and handle the modifications in migrations like the rest? (DROP VIEW && CREATE VIEW)

With the following objective : reducing the number of RunSQL migrations, and make our "hard reset" approach more global.

[Tim Graham]

It seems a discussion on the DevelopersMailingList would be useful to find consensus about how to proceed here.

[Sergey Yurchenko]

You are talking not about squashing itself but about resetting migrations.
I don`t think you need extra command for it. You can synchronize state of models.py and db, remove all migrations and create new ones.
I did it several times in large projects.

[Pascal Briet]

Replying to Sergey Yurchenko:

You are talking not about squashing itself but about resetting migrations.
I don`t think you need extra command for it. You can synchronize state of models.py and db, remove all migrations and create new ones.
I did it several times in large projects.
All history is stored in your CVS

Could you please explain in details what commands you use and what file modifications you do?

I can't see a solution without manually removing the migration history in the DB, which is doable, but quite annoying in an automated deployment.