Ticket:
https://code.djangoproject.com/ticket/23822
Hey folks,
As of now migrations don't expose the model managers to models. Thus it is "impossible" to use e.g. `create_superuser` in a `RunPython` operation. I opened ticket #23822 to keep track of that issue. I propose a solution as implemented in pull request 3687: managers get an optional class attribute `use_in_migrations` that, if True, will mark that manager to be added to migrations by the migration framework. Managers that are part of migrations need to stay around for as long as a migration references the managers. This is the same as with custom model fields or functions passed to field attributes (e.g. `upload_to`).
To keep track of the ordering of the managers (and know which one is really the default), I merged the `Model._meta.abstract_managers` and `.concrete_managers` into a single list and added properties to return the respective subsets instead.
The `managers` attribute on `CreateModel` will be empty without enabling at lease one manager. The normal manager (`models.Manager`) will (almost) never be serialized. Except for the situation where a model's default manager is a manager without migration support, but a custom manager is. In that case a default manager `objects = models.Manager()` will be added explicitly to prevent the non-default manager to become a default manager.
I added migration support for all contrib managers (where appropriate), e.g `UserManager` instead of `BaseUserManager`.
I'd like to get a thorough review before merging, especially regarding the `ModelState.render()` and `from_model()` functions. I think there are some improvements possible I haven't though about.
Thanks
/Markus