Opened 8 years ago

Last modified 8 years ago

#27926 new New feature

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

Reported by: Pascal Briet Owned by: nobody
Component: Migrations Version: 1.10
Severity: Normal Keywords: squashmigrations
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by 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.

Attachments (1)

migrations_reset.py (2.3 KB ) - added by Pascal Briet 8 years ago.

Download all attachments as: .zip

Change History (8)

by Pascal Briet, 8 years ago

Attachment: migrations_reset.py added

comment:1 by Pascal Briet, 8 years ago

Description: modified (diff)

comment:2 by Aymeric Augustin, 8 years ago

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.

in reply to:  2 comment:3 by Pascal Briet, 8 years ago

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,

comment:4 by Pascal Briet, 8 years ago

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.

comment:5 by Tim Graham, 8 years ago

Summary: Squashmigrations --hardAllow squashmigrations to create a fresh set of migrations and delete the old ones
Triage Stage: UnreviewedSomeday/Maybe

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

comment:6 by Sergey Yurchenko, 8 years ago

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

Last edited 8 years ago by Sergey Yurchenko (previous) (diff)

in reply to:  6 comment:7 by Pascal Briet, 8 years ago

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.

Note: See TracTickets for help on using tickets.
Back to Top