{{{
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23657>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23657#comment:1>
* status: new => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/23657#comment:2>