[Django] #27926: Squashmigrations --hard
Django
----------------------------------------+----------------------------------
Reporter: Pascal Briet | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Keywords: squashmigrations
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
----------------------------------------+----------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27926>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
----------------------------------+--------------------------------------
Reporter: Pascal Briet | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Pascal Briet):
* Attachment "migrations_reset.py" added.
Django
----------------------------------+--------------------------------------
Reporter: Pascal Briet | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Pascal Briet:
Old description:
> 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.
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27926#comment:1>
Django
----------------------------------+--------------------------------------
Reporter: Pascal Briet | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27926#comment:2>
Django
----------------------------------+--------------------------------------
Reporter: Pascal Briet | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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,
--
Ticket URL: <https://code.djangoproject.com/ticket/27926#comment:3>
Django
----------------------------------+--------------------------------------
Reporter: Pascal Briet | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27926#comment:4>
Django
old ones
-------------------------------------+-------------------------------------
Reporter: Pascal Briet | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* stage: Unreviewed => Someday/Maybe
Comment:
It seems a discussion on the DevelopersMailingList would be useful to find
consensus about how to proceed here.
--
Ticket URL: <https://code.djangoproject.com/ticket/27926#comment:5>
Django
old ones
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage:
| Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27926#comment:6>
Django
old ones
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Migrations | Version: 1.10
Keywords: squashmigrations | Triage Stage:
| Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Pascal Briet):
Replying to [comment:6 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27926#comment:7>