That's what I originally thought. But if I look at the code, it's entirely
self contained to the existing model. There's no variable in scope that
lets it reach outside the app/model in question.
And thanks for writing the migration feature! I remember when it first came
out. Easily one of my
I suspect the reason for this might be to undo circular references of
ForeignKeys between apps - in this situation, you have to first have a
migration that removes one FK, then in the other app remove the model, then in
the first app remove the model.
I can't quite remember though - but that
3 tests fail when I comment out the code, however, I suspect it's because
of this:
test_autodetector.py#586
It's directly calling _detect_changes before piping it to the optimizer. So
rightly so, it expects more operations than post optimization.
I could be totally wrong though.
Basically,
Did you try deleting this code and seeing if any test failed?
On Sat, 19 Sep 2020 at 17:54, Silvio wrote:
> I've been digging around the 3.1 migration code just out of curiosity, and
> I stumbled upon this in autodetector.py#772:
>
> for name in sorted(related_fields):
>
I've been digging around the 3.1 migration code just out of curiosity, and
I stumbled upon this in autodetector.py#772:
for name in sorted(related_fields):
self.add_operation(
app_label,
operations.RemoveField(
