Shai Berger wrote: > On Thursday 09 October 2014 09:53:44 Andrew Godwin wrote: > > > > The logic is not too complex, but the feature would need to be > > dependency-aware and delete any migrations that depended on the updated > > migration before it re-ran makemigrations; in addition, if no migration > > name is provided (as to how makemigrations runs by default), the strategy > > might change a bit. > > > There are a few other minor complications; for example, the script suggested > might fail if the last migration depended on more than one migration in the > local app (which naturally happens if you needed "makemigrations --merge"). > > Also, I'd be quite apprehensive about updating migrations which have > dependents. It seems like a high potential for breakage.
Yeah. I already figured out that it's probably the best to refuse to update if a migration has dependents. My next question would have been whether it's possible that a migration has multiple local dependencies, but you already answered that. Updating a migration is quite a limited use case, so it's probably best to also refuse to update a merge migration. Thanks, Petri -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20141010045431.GA21601%40p29. For more options, visit https://groups.google.com/d/optout.
