> If we were going to make something like this that is Django > specific, we’d normally want to have a working, battle-tested third party > implementation before considering merging it to core.
Let me try to reformulate it in different terms. It’s not about some new big workflow. It’s not about some new big feature. It’s not about a major change to an existing feature. It’s about fixing an off-by-one error in the `migrate` management command. The underlying machinery is 100% comfortable with doing the thing being discussed, there’s just no way to instruct it to do so using manage.py migrate. If there are 10 normal migrations and 10 merge migrations, the `migrate` command will unapply 19 of those without incident, but it can’t unapply the last one, simply because the command line interface is insufficient to tell it what exactly needs to be done. That’s because when reversing, the command line argument is not the migration to reverse but rather the first migration not to reverse, and that’s ambiguous. That’s all there is to it. The patch basically adds one line in an `if`: https://github.com/django/django/pull/13781/files#diff-973e0df4f8467492bce02726075ea76ca3f574945cc3b9f81247758dce7e6b0fR43 and the rest is boilerplate. It’s as though the interface to a chess program would accept all moves except the lexicographically first one, which happens to be Ba1, and we would be arguing that a1 is a poor square for a bishop and that players should not play such a move. The suggested change does not introduce any new data integrity concerns, it merely allows the player to play any legal move. Does this clarify the intent of the patch? -- 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2262200.CLe3rPZDcf%40xps.
