Джанго Общие отношения с Джанго Админ - PullRequest
Новая
       32

Джанго Общие отношения с Джанго Админ

3 голосов
/ 19 января 2010

У меня есть проект Django с моделью «Адрес». Это используется в нескольких местах - моделью «Профиль пользователя», моделью «Больница», моделью «Институция» и т. Д.

Я использую общие отношения Django, чтобы каждый из этих объектов мог создать внешний ключ для Address.

Однако, это, кажется, вызывает некоторые странности у администратора Django (или, возможно, я не совсем правильно понимаю, как это должно использоваться). В Django Admin, если я пытаюсь создать адрес, я вижу поля для «Тип контента» и «Идентификатор объекта». Модель не будет проверена / сохранена, если они не заполнены. Не уверен, что положить в них.

Дело в том, что я хотел иметь возможность создавать автономные объекты Address. Затем, когда я создаю профиль пользователя или больницу, я могу связать их с объектами Address, включая возможность нескольких ссылок на один и тот же объект Address.

Как мне использовать администратора Django с общими отношениями?

Кроме того, я также собираюсь использовать django-reversion для контроля версий моделей, но не уверен, что это вызовет какие-либо проблемы с общими отношениями и администратором?

Cheers, Victor

Редактировать: я должен просто добавить, вот мой предыдущий вопрос, который я опубликовал. Адреса и строки:

Django - Проектирование отношений модели - Интерфейс администратора и Inline

Основываясь на ответах, приведенных там, вот почему модель Address - это модель с внешним ключом. А поскольку обычное поле FK может указывать только на один тип объекта, поэтому мы используем общие отношения.

Каждый пользователь / отделение / больница и т. Д. Может (и в большинстве случаев будет) иметь несколько адресов.

Один и тот же адрес может использоваться несколькими объектами, но это реже, и дублирование здесь хорошо, я думаю, верно?

Так что это будет один ко многим от пользователя / отделения / больницы до адресов.

В этом первоначальном вопросе они также предложили использовать абстрактные классы и разные модели адресов для каждого объекта, который нуждался в адресе. Я до сих пор не уверен, что это лучший подход или есть способ заставить GenericRelations работать с тем, что я пытаюсь сделать здесь.

1 Ответ

3 голосов
/ 19 января 2010

Использование общих отношений в django это именно то, что нужно. От ForeignKey до ContentType (content_type) и IntegerField для обозначения идентификатора экземпляра (object_id). Это полезно, если вы не знаете, на какой тип содержимого указывает ForeignKey. Поскольку вы знаете, что нацелены на модель Address, вы хотите использовать обычные ForeignKey(Address) вместо общих отношений.

В ответ на ваш комментарий

На самом деле его гораздо проще использовать ForeignKey, так как вам не нужно проходить через ContentType. 

class Address(models.Model):
  street=models.CharField(max_length=100)
  city=models.CharField(max_length=100)


class Hospital(models.Model):
  name=models.CharField(max_length=100)
  created=models.DateTimeField()
  address=models.ForeignKey(Address, related_name="hospitals")

class Institution(models.Model):
  name=models.CharField(max_length=100)
  address=models.ForeignKey(Address, related_name="institutions")


>>> instance=Institution.objects.get(id=1)
>>> instance.address.city
>>> address=Address.objects.get(id=1)
>>> address.institutions.all() 
>>> address.hospitals.all()

Ваши модели будут делиться адресами? Т.е. могут ли Hospital и Institution и, возможно, UserProfile все указывать на один и тот же экземпляр адреса? Или более вероятно, что у каждого будет свой адрес? Я пытаюсь понять, почему вы создали отдельный класс Address. Чтобы избежать повторного ввода одних и тех же полей в каждый класс, вы можете использовать класс абстрактной модели и создать его подкласс. Или вам может понадобиться OneToOneField, который является двухсторонним указателем между двумя экземплярами.

...