ModelForm is not using the plain manager for foreign keys

[eagle-r]

According to the documentation, Django will use an instance of the plain manager instead of the default manager for related fields (see ​https://docs.djangoproject.com/en/1.7/topics/db/managers/#using-managers-for-related-object-access).

However, the ModelForm initialisation code is using the default manager instead when initialising the fields during loading (see django/db/models/fields/related.py:1749)

So, if you have a model that is using a custom default manager, the modelform attempts to use this manager instead leading to some very unexpected side effects particularly when running the server and loading up the code initially.

[Collin Anderson]

The default manager is the first manager defined, not necessarily a "plain" manager, right?
​https://github.com/django/django/blob/d49183e4bed8ecf21faad44372ea15ff00f781b5/django/db/models/manager.py#L127-129

[Tim Graham]

Collin, yes that's what's documented in the ​default managers docs.

I am not sure about this. The behavior doesn't seem to be well defined as I couldn't find any documentation about this and no tests fail if I make this change (please correct me if this is the wrong line; this is the closest line I could find on stable/1.7.x to the one you referenced):

django/db/models/fields/related.py

@@ -1759 +1759 @@
                              (self.name, self.rel.to))
         defaults = {
             'form_class': forms.ModelChoiceField,
-            'queryset': self.rel.to._default_manager.using(db),
+            'queryset': self.rel.to._base_manager.using(db),
             'to_field_name': self.rel.field_name,
         }
         defaults.update(kwargs)

On the other hand, I could see the current behavior as expected and changing it could cause problems for people relying on it.

[Tim Graham]

Lacking any follow-up from the reporter, I'm going to close as "needs info". Feel free to reopen if you can describe more about the problem here.