[Django] #31844: When running migrations, the origional starting migrations should be shown.

12 views

Skip to first unread message

Django

unread,

Jul 31, 2020, 11:52:31 AM7/31/20

to django-...@googlegroups.com

#31844: When running migrations, the origional starting migrations should be shown.
-----------------------------------------+------------------------
Reporter: Timothy Hobbs | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
In order to make it easier to roll back migrations, it would be quite
useful to show the migrations that were applied immiediately before the
run migrations. For example:

Instead of displaying:

{{{
Operations to perform:

Apply all migrations: admin, admin_tools_stats, advanced_filters, aklub,
auth, celery_monitor, computedfields, contenttypes, dashboard,
django_celery_beat, django_nyt, flexible_filter_conditions, helpdesk,
import_export_celery, import_export_celery_edit, interactions, menu,
oauth2_provider, post_office, repolinks, sessions, sites, smmapdfs,
smmapdfs_edit, thumbnail, wiki, wiki_attachments, wiki_images,
wiki_notifications

Running migrations:

Applying admin.0002_auto_20190108_1629... OK

Applying admin.0002_auto_20181114_1448... OK

Applying admin.0003_merge_20190120_1444... OK

Applying admin.0004_auto_20190826_2034... OK

Applying admin.0005_auto_20190904_1547... OK

Applying admin.0006_auto_20190909_0912... OK
}}}

There would be:

{{{
Operations to perform:

Starting from:

admin.0001_auto_20180108_1629

Running migrations:

Applying admin.0002_auto_20190108_1629... OK

Applying admin.0002_auto_20181114_1448... OK

Applying admin.0003_merge_20190120_1444... OK

Applying admin.0004_auto_20190826_2034... OK

Applying admin.0005_auto_20190904_1547... OK

Applying admin.0006_auto_20190909_0912... OK
}}}

This way it would be easy to roll back the migration simply by copying the
origional migration name

{{{
./manage.py migrate admin.0001_auto_20180108_1629
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/31844>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

Aug 4, 2020, 3:44:38 AM8/4/20

to django-...@googlegroups.com

#31844: When running migrations, the origional starting migrations should be shown.

-------------------------------+--------------------------------------

Reporter: Timothy Hobbs | Owner: nobody

Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 3.0
Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

-------------------------------+--------------------------------------
Changes (by Carlton Gibson):

* status: new => closed
* resolution: => wontfix

Comment:

We already have `showmigrations` to see the applied (and unapplied) state.
As such I'm inclined to wontfix here.

In any case, the applied migration state isn't a single migration, but the
leaf migrations for each app. You've got (I think) 29 apps listed there,
so you'd need 29 lines of output. Maybe we could reduce that analysing-out
dependencies, but it doesn't seem worth the complexity: just use
`showmigrations`.