Интерфейс администратора Django не использует __unicode __ () подкласса

Django (и реляционные базы данных в целом) так не работают. Даже при использовании ORM, такого как Django, вы не работаете с подобными иерархиями классов.

Есть два возможных решения вашей проблемы:

(1) присвойте «имя» модели Animal, затем добавьте объекты с именами из ['Dog', 'Cat']. Это покажет имена животных в поле выбора внешнего ключа.

(2) Если вы действительно нужно связываете свой внешний ключ с разными моделями (что на самом деле не является обычным способом использования СУБД), вам следует прочитать о Родовые отношения в документации по фреймворку contenttypes.

Однако мой совет (1).

Вам нужен Абстрактный базовый класс («виртуальный» ничего не значит в Python.)

Из документации:

class CommonInfo(models.Model):
    name = models.CharField(max_length=100)
    age = models.PositiveIntegerField()

    class Meta:
        abstract = True

Редактировать

«В объектно-ориентированном программировании, когда вы вызываете object.method (), вы должны получить реализацию самого нижнего подкласса».

Правда. Но не вся история.

Это не проблема ОО. Или даже проблема с Python или Django. Это проблема ORM.

Возникает вопрос: «Какой объект реконструируется в конце ссылки ФК?» И ответ в том, что нет стандартного, очевидного ответа о том, как обрабатывать преобразование из значения FK в объект.

У меня есть строка в AnimalHome со значением animals 42. Это относится к Animal.objects.get(pk=42). Какой подкласс животных? Кошка? Собака? Как уровень ORM узнает, должен ли он работать с Dog.objects.get(pk=42) или Cat.objects.get(pk=42)?

«Но подождите», - скажете вы. «Он должен получать объект Animal, а не объект Dog или Cat». Вы можете надеяться на это, но Django ORM работает не так. Каждый класс представляет собой отдельную таблицу. Cat и Dog - по определению - отдельные таблицы с отдельными запросами. Вы не используете хранилище объектов. Вы используете ORM для реляционных таблиц.

Редактировать

Во-первых, ваш запрос работает только в том случае, если Dog и Cat используют общий генератор ключей и не имеют перекрывающегося набора PK.

Если у вас есть собака с PK 42 и кошка с PK 42, у вас проблема. А поскольку вы не можете легко контролировать генерацию ключей, ваше решение не может работать.

Идентификация типа во время выполнения неправильная. Он не является объектно-ориентированным во многих отношениях. Практически все, что вы можете сделать, чтобы избежать RTTI, лучше, чем постоянно расширяющаяся последовательность операторов if для различения подклассов.

Однако модель, которую вы пытаетесь построить, является патологической проблемой для систем ORM. Действительно, настолько патологически, что я почти готов поспорить, что это домашнее задание. [Существуют также патологические проблемы для чистых систем SQL. Они часто используются как домашнее задание.]

Проблема в том, что ORM не может делать то, что, по вашему мнению, должно делать. Итак, у вас есть два варианта.

• Прекратите использовать Django.
• Делайте то, что Django делает напрямую.
• Нарушайте принципы объектно-ориентированного проектирования и прибегайте к хрупким вещам, таким как RTTI, которые значительно затрудняют добавление нового подкласса животных.

Рассмотрим этот способ сделать RTTI - он включает имя класса, а также PK

KIND_CHOICES = (
   ( "DOG", "Dog" ),
   ( "CAT", "Cat" ),
)

class Animal( models.Model ):
    kind = models.CharField( max_length= 1, choices=KIND_CHOICES )
    fk = models.IntegerField()
    def get_kind( self ):
        if kind == "DOG":
            return Dog.objects.get( pk = fk )
        elif kind == "CAT":
            return Cat.objects.get( pk = fk )

Это соответствует тому, что предложил С.Лотт, но без if / elif / ..., который может становиться все более неудобным и сложным в обслуживании по мере роста числа подклассов, которые вам нужно поддерживать.

class Cat(models.Model):
    def __unicode__(self):
        return u'A Cat!'

class Dog(models.Model):
    def __unicode__(self):
        return u'A Dog!'        

class Eel(models.Model):
    def __unicode__(self):
        return u'An Eel!'        

ANIMALS = {
    'CAT': {'model': Cat, 'name': 'Cat'},
    'DOG': {'model': Dog, 'name': 'Dog'},
    'EEL': {'model': Eel, 'name': 'Eel'},
}
KIND_CHOICES = tuple((key, ANIMALS[key]['name']) for key in ANIMALS)

class Animal(models.Model):
    kind = models.CharField(max_length=3, choices=KIND_CHOICES)
    fk = models.IntegerField()
    def get_kind(self):
        return ANIMALS[self.kind]['model'].objects.get(pk=self.fk)
    def __unicode__(self):
        return unicode(self.get_kind())

Что-то очень похожее можно сделать и с наследованием нескольких таблиц в Django (поищите это в документации Django). Например:

ANIMALS = {
    'CAT': {'model_name': 'Cat', 'name': 'Cat'},
    'DOG': {'model_name': 'Dog', 'name': 'Dog'},
    'EEL': {'model_name': 'Eel', 'name': 'Eel'},
}
KIND_CHOICES = tuple((key, ANIMALS[key]['name']) for key in ANIMALS)

class Animal(models.Model):
    kind = models.CharField(max_length=3, choices=KIND_CHOICES)
    def get_kind(self):
        return getattr(self, ANIMALS[self.kind]['model_name'].lower())
    def __unicode__(self):
        return unicode(self.get_kind())

class Cat(Animal):
    def __unicode__(self):
        return u'A Cat!'

class Dog(Animal):
    def __unicode__(self):
        return u'A Dog!'        

class Eel(Animal):
    def __unicode__(self):
        return u'An Eel!'        

Я лично предпочитаю второй вариант, поскольку в экземплярах подклассов все поля будут автоматически определены в родительском классе, что позволяет получить более четкий и сжатый код. (Например, если бы у класса Animal было поле 'пол', то Cat.objects.filter (пол = 'MALE') работал бы).

ForeignKey (Animal) - это просто ссылка внешнего ключа на строку в таблице Animal. В базовой схеме SQL нет ничего, что указывало бы на то, что таблица используется в качестве суперкласса, поэтому вы получаете обратно объект Animal.

Чтобы обойти это:

Во-первых, вы хотите, чтобы базовый класс не был абстрактным. Это в любом случае необходимо для ForeignKey, а также гарантирует, что Dog и Cat будут иметь отдельные наборы первичных ключей.

Теперь Django реализует наследование с помощью OneToOneField. Из-за этого экземпляр базового класса, у которого есть экземпляр подкласса, получает ссылку на этот экземпляр с соответствующим именем. Это означает, что вы можете:

class Animal(models.Model):
    def __unicode__(self):
        if hasattr(self, 'dog'):
            return self.dog.__unicode__()
        elif hasattr(self, 'cat'):
            return self.cat.__unicode__()
        else:
            return 'Animal'

Это также отвечает на ваш вопрос Беру о юникод (), который зависит от других атрибутов подкласса. На самом деле вы сейчас вызываете соответствующий метод в экземпляре подкласса.

Теперь это говорит о том, что, поскольку Django уже ищет экземпляры подкласса за кулисами, код может просто пройти весь путь и вернуть экземпляр Cat или Dog вместо Animal. Вам придется обсудить этот вопрос с разработчиками. :)

Что касается общих отношений, обратите внимание, что обычные запросы Django не могут охватывать отношения GenerecForeignKey. Использование наследования нескольких таблиц позволяет избежать этой проблемы за счет менее общего решения.

Из документов:

Due to the way GenericForeignKey is implemented, you cannot use such fields directly with filters (filter() and exclude(), for example) via the database API. They aren't normal field objects. These examples will not work:

# This will fail
>>> TaggedItem.objects.filter(content_object=guido)
# This will also fail
>>> TaggedItem.objects.get(content_object=guido)

Вы можете использовать фреймворк контента django

Я сделал здесь пример того, как реализовать вам модели ->

https://github.com/jmg/django_content_types_example/blob/master/generic_models/models.py

А здесь вы можете увидеть, как пользоваться orm ->

https://github.com/jmg/django_content_types_example/blob/master/generic_models/tests.py