Migrations framework doesn't properly handle factory-generated base classes.

[jfialkoff]

It is sometimes useful to construct models using factories. The code below shows one example of this. Other useful factories may or may not have fields (e.g., I have a base class factory that I use to add properties to an object with the urls for the object listing, edit page, create page and delete page).

def address_mixin_factory(address_required=True, city_required=True, state_required=True):
    # build base abstract model with the fields address, city and state and assign blank=True/False depending on the arguments.
    return AddressMixin

class FullAddress(address_mixin_factory(), models.Model):
    pass

class PartialAddress(address_mixin_factory(address_required=False), models.Model):
    pass

When you use Django migrations to migrate a model like this, the resulting migration file will have something like bases=(AddressMixin, models.Model) in the call to CreateModel where, instead, we would want bases=(address_mixin_factory(), models.Model). Also, while I have not tested this, I'm assuming the fields specified in the call to CreateModel will also be lacking the fields contributed by the factory-created base class.

[Carl Meyer]

This strikes me as an atypical edge-case where the only feasible answer is "modify the generated migration." Migration files are editable Python code for a reason; autodetection will never handle everything someone might do.

In this case, I don't think it is possible for the autodetector to handle this the way you want - it can't know via runtime introspection that your base class was created via factory. (Well, with __qualname__ in Python 3 it might be possible, but we have to maintain Python 2 compatibility for quite some time still).

Closing wontfix; if any other core dev with more hands-on migration experience disagrees, feel free to reopen.