#31837: Possible manager migration bug
--------------------------------+--------------------------------------
Reporter: Gordon Wrigley | Owner: nobody
Type: Uncategorized | Status: closed
Component: Migrations | Version: 3.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+--------------------------------------
Comment (by felixxm):
> 2: They are both actually instances of the Django base manager so they
have the same setting for use_in_migrations (I presume True)
No, by default the `use_in_migrations` attribute is `False`.
Let's start from the beginning. Django includes in migrations a base
manager, a default manager and managers with `use_in_migrations` set to
`True`. The order matters because the first `Manager` Django encounters
(in the order in which they’re defined in the model) has a special status,
it's interpreted as the “default” Manager (see
[https://docs.djangoproject.com/en/3.0/topics/db/managers/#default-
managers docs]). Moreover to prevent unnecessary migrations we added in
#26643 check to omit migrations if only one manager meet requirements and
it's called `objects`.
> 3: If you swap the order of the manager declarations around in the
source code it no longer generates any migration.
Yes because the first (and the default) manager is called `objects`, and
it's the only manager that meets requirements to be included in
migrations. In such cases we omit it to prevent unnecessary migrations
(see #26643). The second manager doesn't have `use_in_migrations` set to
`True` so it's ignored.
> 4: If you leave the order as is in the linked commit but additionally
redeclare the objects manager in the concrete model classes it again
decides no migration is needed
Yes because that changes the default manager to `objects`.
>
> If this example seems a lil simplistic that's because I was trying to
get a minimal reproduction, here's one that is structurally equivalent to
what I actually have:
> https://github.com/tolomea/django-
tutorial/commit/f247b6ddc5b2b689ec7ec0ede7cb0bc28c99db0c
> Where everything prefixed lib is in a 3rd party library.
>
> In there you can see that overriding objects on the concrete model
causes both to be added to the migration.
> Switching the order of the managers around also leads to a migration
adding both managers to both concrete models.
`lib_manager` is added because it's declared as a base manager, `objects`
is added because it's a default manager, so we have two managers which
meets requirements. That's why both are included in migrations.
--
Ticket URL: <https://code.djangoproject.com/ticket/31837#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.a9d45eb137f16590663c72a94f4f9bb0%40djangoproject.com.
