Modify ↓
Ticket #269 (closed enhancement: wontfix)
Support some kind of --refresh mechanism in 'startmigration'
| Reported by: | elsdoerfer@… | Owned by: | andrew |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.7 |
| Component: | commands | Version: | 0.6 |
| Keywords: | Cc: |
Description
If find that from time to time, I make a model change while working on a commit, create (and possibly apply) the migration, only to later find out I have to further amend the change, or make another one that fits the existing migration (i.e. adding another field to a new table).
It would be convenient if there were some kind of --refresh option that would replace the currently active migration.
This could go even further and also support rollback of the migration in question, if applied (though I'm not sure how that would best be implemented, command-design wise - doing so automatically may not be a good idea).
Attachments
Change History
Note: See
TracTickets for help on using
tickets.

Hrm, seems I missed this when it was first opened.
I don't see a common enough use case here, or indeed one I want to encourage; it's generally best not to rollback and delete migrations once they're committed to a VCS, and while that may not be the case here, I can't help but think it might encourage bad behaviour.
I imagine you could get similar results with a small shell script that worked out the name of the last migration using "./manage.py migrate appname --list", and then just migrated back before it and deleted it.