Як отримати доступ до дочірніх класів об’єкта в django, не знаючи назви дочірнього класу?

У Django, коли у вас є батьківський клас і кілька дочірніх класів, які успадковуються від нього, ви зазвичай отримуєте доступ до дочірнього за допомогою parentclass.childclass1_set або parentclass.childclass2_set, але що, якщо я не знаю імені конкретного дочірнього класу, який я хочу?

Чи є спосіб отримати пов’язані об’єкти у напрямку батьків-> дочірній матеріал, не знаючи назви дочірнього класу?

( Оновлення : Для Django 1.2 та новіших версій, які можуть слідувати за запитами select_related у зворотних відносинах OneToOneField (і, отже, за ієрархіями спадкування), існує краща техніка, яка не вимагає додавання real_typeполя в батьківській моделі. Він доступний як InheritanceManager у django-model-utils .)

Звичайний спосіб зробити це - додати ForeignKey до ContentType на батьківській моделі, яка зберігає тип вмісту відповідного класу "листя". Без цього вам може знадобитися виконати чимало запитів у дочірніх таблицях, щоб знайти примірник, залежно від того, наскільки великим є ваше дерево успадкування. Ось як я це зробив в одному проекті:

from django.contrib.contenttypes.models import ContentType
from django.db import models

class InheritanceCastModel(models.Model):
    """
    An abstract base class that provides a ``real_type`` FK to ContentType.

    For use in trees of inherited models, to be able to downcast
    parent instances to their child types.

    """
    real_type = models.ForeignKey(ContentType, editable=False)

    def save(self, *args, **kwargs):
        if self._state.adding:
            self.real_type = self._get_real_type()
        super(InheritanceCastModel, self).save(*args, **kwargs)
    
    def _get_real_type(self):
        return ContentType.objects.get_for_model(type(self))
            
    def cast(self):
        return self.real_type.get_object_for_this_type(pk=self.pk)
    
    class Meta:
        abstract = True

Це реалізовано як абстрактний базовий клас, щоб зробити його багаторазовим; ви також можете розмістити ці методи та FK безпосередньо на батьківському класі у вашій ієрархії успадкування.

Це рішення не буде працювати, якщо ви не можете змінити батьківську модель. У цьому випадку ви майже застрягли перевіряти всі підкласи вручну.

У Python, давши ("новий стиль") клас X, ви можете отримати його (прямий) підклас за допомогою X.__subclasses__(), який повертає список об'єктів класу. (Якщо ви хочете "подальших нащадків", вам також доведеться зателефонувати __subclasses__до кожного з прямих підкласів тощо, тощо - якщо вам потрібна допомога щодо того, як ефективно це зробити в Python, просто запитайте!).

Після того, як ви якось визначили дочірній клас інтересів (можливо, усі вони, якщо ви хочете екземпляри всіх дочірніх підкласів тощо), getattr(parentclass,'%s_set' % childclass.__name__)повинні допомогти (якщо дочірній клас називається 'foo', це так само, як доступ parentclass.foo_set- ні більше, ні менше ). Знову ж таки, якщо вам потрібні роз’яснення чи приклади, запитайте!

Рішення Карла є хорошим, ось один із способів зробити це вручну, якщо є кілька пов’язаних дочірніх класів:

def get_children(self):
    rel_objs = self._meta.get_all_related_objects()
    return [getattr(self, x.get_accessor_name()) for x in rel_objs if x.model != type(self)]

Він використовує функцію з _meta, яка не гарантується стабільною в міру розвитку django, але вона робить трюк і може використовуватися на льоту, якщо це необхідно.

Виявляється, що мені справді було потрібно:

Моделювати успадкування за типом вмісту та менеджером, який усвідомлює спадщину

Це для мене прекрасно спрацювало. Хоча дякую всім іншим. Я багато чому навчився, лише читаючи ваші відповіді!

Для цього можна використовувати django-polymorphic .

Це дозволяє автоматично повертати похідні класи до їх фактичного типу. Він також забезпечує підтримку адміністратора Django, більш ефективну обробку запитів SQL, а також підтримку моделі проксі, вбудованих рядків та набору форм.

Базовий принцип, здається, багато разів винаходили (включаючи Пліску .specificта приклади, викладені в цій публікації). Однак потрібно більше зусиль, щоб переконатися, що це не спричиняє проблем із N-запитом, або приємно інтегруватися з адміністратором, наборами форм / рядками або сторонніми програмами.

Ось моє рішення, воно знову використовує, _metaтому не гарантовано буде стабільним.

class Animal(models.model):
    name = models.CharField()
    number_legs = models.IntegerField()
    ...

    def get_child_animal(self):
        child_animal = None
        for r in self._meta.get_all_related_objects():
            if r.field.name == 'animal_ptr':
                child_animal = getattr(self, r.get_accessor_name())
        if not child_animal:
            raise Exception("No subclass, you shouldn't create Animals directly")
        return child_animal

class Dog(Animal):
    ...

for a in Animal.objects.all():
    a.get_child_animal() # returns the dog (or whatever) instance

Ви можете досягти цього, шукаючи всі поля в батьківському елементі, які є екземпляром django.db.models.fields.related.RelatedManager. З вашого прикладу здається, що дочірні класи, про які ви говорите, не є підкласами. Правда?

Альтернативний підхід з використанням довірених осіб можна знайти в цій публікації блозі . Як і інші рішення, він має свої переваги та зобов'язання, які дуже добре викладено в кінці поста.