Ticket #269 (closed enhancement: wontfix)

Opened 5 years ago

Last modified 5 years ago

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).

Change History

comment:1 Changed 5 years ago by andrew

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone set to 0.7

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.

Note: See TracTickets for help on using tickets.