Ответ 1

Является ли это глобальной настройкой? Итак, если я укажу этот атрибут на одном из менеджеров модели, будет ли он использоваться глобально всеми классами модели?

Если я понял, что вы подразумеваете под глобальным, ответ - нет. Он будет использоваться только для класса, если он установил менеджер по умолчанию (первый менеджер, указанный в классе). Вы можете повторно использовать диспетчер в нескольких моделях, и этот атрибут будет влиять только на те классы, для которых он был менеджером по умолчанию.

Это то, что я думал, что пример поможет с пониманием. Позволяет использовать следующие модели членов и профиля, связанные друг с другом:

from django.db import models  

class Member(models.Model):
    name = models.CharField(max_length=100)
    active = models.BooleanField()

    def __unicode__(self):
        return self.name


class Profile(models.Model):
    member = models.OneToOneField(Member)
    age = models.PositiveIntegerField()

    def __unicode__(self):
        return str(self.age)

Мы создадим пару членов, активный Джон и неактивный Фил, и настроим профиль для каждого из них:

>>> m1 = Member(name='John', active=True)
>>> m1.save()
>>> p1 = Profile(member=m1, age=18)
>>> p1.save()
>>> m2 = Member(name='Phil', active=False)
>>> m2.save()
>>> p2 = Profile(member=m2, age=35)
>>> p2.save()

Как Django сохраняет отношения

Во-первых, давайте посмотрим, как Django сохраняет отношения. Мы рассмотрим профиль Джона и рассмотрим его пространство имен:

>>> p = Profile.objects.get(id=1)
>>> p.__dict__
{'age': 18, '_state': <django.db.models.base.ModelState object at 0x95d054c>, 'id': 1, 'member_id': 1}

Здесь мы видим, что отношение определяется путем хранения значения идентификатора экземпляра-члена. Когда мы ссылаемся на атрибут member, Django использует диспетчер для извлечения деталей элемента из базы данных и создания экземпляра. Кстати, эта информация затем кэшируется, если мы хотим использовать ее снова:

>>> p.member
<Member: John>
>>> p.__dict__
{'age': 18, '_member_cache': <Member: John>, '_state': <django.db.models.base.ModelState object at 0x95d054c>, 'id': 1, 'member_id': 1}

Какой менеджер использовать

Если не указано иное, Django использует стандартный менеджер для этого поиска отношений, а не какой-либо настраиваемый менеджер, добавленный в модель. Например, предположим, что мы создали следующего менеджера только для возвращения активных членов:

class ActiveManager(models.Manager):
    def get_query_set(self):
        return super(ActiveManager, self).get_query_set().filter(active=True)

Затем мы добавили его в нашу модель-член как менеджер по умолчанию (в реальной жизни это плохая идея и торговля, поскольку ряд утилит, таких как команда управления dumpdata, использует исключительно менеджер по умолчанию и, следовательно, менеджер по умолчанию, который отфильтровывает экземпляры, может привести к потере данных или подобным неприятным побочным эффектам):

class Member(models.Model):
    name = models.CharField(max_length=100)
    active = models.BooleanField()

    objects = ActiveManager()

    def __unicode__(self):
        return self.name

Теперь, когда менеджер отфильтровывает неактивных пользователей, мы можем только получить членство Джона из базы данных:

>>> Member.objects.all()
[<Member: John>]

Однако оба профиля доступны:

>>> Profile.objects.all()
[<Profile: 18>, <Profile: 35>]

И поэтому мы можем перейти к неактивному элементу через профиль, поскольку поиск отношений по-прежнему использует стандартный менеджер, а не наш пользовательский:

>>> p = Profile.objects.get(id=2)
>>> p.member
<Member: Phil>

Однако, если мы теперь установим атрибут use_for_related_fields в наш менеджер, это скажет Django, что он должен использовать этот менеджер для поиска отношений:

class ActiveManager(models.Manager):
    use_for_related_fields = True

    def get_query_set(self):
        return super(ActiveManager, self).get_query_set().filter(active=True)

Следовательно, мы больше не можем получать запись о членстве Фила в его профиле:

>>> p = Profile.objects.get(id=2)
>>> p.member
---------------------------------------------------------------------------
DoesNotExist                              Traceback (most recent call last)

/home/blair/<ipython console> in <module>()

/usr/lib/pymodules/python2.6/django/db/models/fields/related.pyc in __get__(self, instance, instance_type)
    298             db = router.db_for_read(self.field.rel.to, instance=instance)
    299             if getattr(rel_mgr, 'use_for_related_fields', False):
--> 300                 rel_obj = rel_mgr.using(db).get(**params)
    301             else:
    302                 rel_obj = QuerySet(self.field.rel.to).using(db).get(**params)

/usr/lib/pymodules/python2.6/django/db/models/query.pyc in get(self, *args, **kwargs)
    339         if not num:
    340             raise self.model.DoesNotExist("%s matching query does not exist."
--> 341                     % self.model._meta.object_name)
    342         raise self.model.MultipleObjectsReturned("get() returned more than one %s -- it returned %s! Lookup parameters were %s"
    343                 % (self.model._meta.object_name, num, kwargs))

DoesNotExist: Member matching query does not exist.

Обратите внимание, что это действует только в том случае, если пользовательский менеджер является менеджером по умолчанию для модели (т.е. это первый менеджер). Итак, попробуйте использовать стандартный менеджер в качестве менеджера по умолчанию, а наш пользовательский - как дополнительный менеджер:

class Member(models.Model):
    name = models.CharField(max_length=100)
    active = models.BooleanField()

    objects = models.Manager()
    active_members = ActiveManager()

    def __unicode__(self):
        return self.name

Оба менеджера работают, как ожидалось, при непосредственном рассмотрении участников:

>>> Member.objects.all()
[<Member: John>, <Member: Phil>]
>>> Member.active_members.all()
[<Member: John>]

И поскольку менеджер по умолчанию может извлекать все объекты, поиск отношений также преуспевает:

>>> Profile.objects.get(id=2)
>>> p.member
<Member: Phil>

Реальность

Сделав это так, вы теперь узнаете, почему я выбрал индивидуальные отношения для примерных моделей. Оказывается, что в действительности (и в противоречии с документацией) атрибут use_for_related_fields используется только для отношений "один к одному". Внешние ключи и отношения "многие ко многим" игнорируют это. Это билет # 14891 в трекер Django.

Возможно ли иметь одного менеджера модели для одного отношения, а другое - для другого отношения с той же моделью?

Нет. Хотя в это обсуждение упомянутой выше ошибки это стало возможным в будущем.

Ответ 2

Короткий ответ: до тех пор, пока эта ошибка не будет исправлена, 'use-for-related-fields' не работает в django, за исключением отношений "один-к-одному" , поэтому не беспокойтесь, если ваш случай использования составляет m2m или m2one, или вы будете разочарованы.