Opened 6 years ago
Closed 6 years ago
#30186 closed New feature (fixed)
Show applied datetime in showmigrations
Reported by: | Timothy Schilling | Owned by: | Timothy Schilling |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Normal | Keywords: | migrations showmigrations |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
My idea is to add the applied datetime value to the showmigrations command.
I've run into the case where I'm working on a branch that involves a number of migrations across various apps, but then have to switch to a different branch which has different migrations. It can be troublesome to determine which migrations are new and need to be rolled back. I've recently started looking at the django_migrations table sorted on the applied column to determine which I've run recently. This would make switching between branches involving conflicting migrations easier.
There was some brief discussion here.
I've initially implemented this so that it would only apply to the --list
option with a --verbosity
of 2 and above. Here's what I have so far. I wasn't sure how to handle backporting.
Edited to strikeout old PR and reference the one to origin.
Change History (8)
comment:1 by , 6 years ago
Has patch: | unset |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 6 years ago
Has patch: | set |
---|---|
Patch needs improvement: | set |
comment:3 by , 6 years ago
Has patch: | unset |
---|---|
Patch needs improvement: | unset |
Whoops, didn't realize the link was a PR to a fork and not to origin!
comment:4 by , 6 years ago
Description: | modified (diff) |
---|---|
Has patch: | set |
Owner: | changed from | to
Status: | new → assigned |
comment:5 by , 6 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
We're past the feature freeze for 2.2, so please target the patch for 3.0 and send the pull request to django/django rather than to your fork.