Вы могли бы найти, что библиотека XNA имеет некоторую поддержку работы с WAV и т.д., если Вы готовы спуститься по тому маршруту. Это разработано для работы с C# для игрового программирования, так мог бы просто заботиться о том, в чем Вы нуждаетесь.
Я хотел бы расширить решение @thornomad.
Прямое расширение класса User Django может вызвать всевозможные проблемы с внутренними механизмами django.auth. То, что я сделал в подобной ситуации, - это именно то, что предлагает @thornomad: я создал свою собственную модель UserProfile, связанную один к одному с моделью пользователя Django, в которой я хранил дополнительные пользовательские данные и от которых я унаследовал модели для разных типов. пользователей.
Что-то, что соответствует тому, что вы описали:
class UserProfile(models.Model):
user = models.OneToOneField(User, blank=True, related_name='profile')
class Meta:
abstract = True
class PositionHolderUserProfile(UserProfile):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=30)
landline = models.CharField(blank=True, max_length=20)
mobile = models.CharField(blank=True, max_length=20)
created_by = models.ForeignKey(PositionHolderUserProfile, editable=False, blank=True, related_name="created_users")
modified_by = models.ForeignKey(PositionHolderUserProfile, editable=False, blank=True, related_name="modified_users")
class Principal(PositionHolderUserProfile):
branchoffice = models.ForeignKey(BranchOffice)
class Administrator(PositionHolderUserProfile):
superior = models.ForeignKey(Principal, related_name="subordinates")
province = models.ForeignKey(Province)
class Coordinator(PositionHolderUserProfile):
superior = models.ForeignKey(Administrator, related_name="subordinates")
class Company(UserProfile):
name = models.CharField(max_length=50)
class Product(models.Model):
name = models.CharField(max_length=50)
produced_by = models.ForeignKey(Company)
class Buyer(UserProfile):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=30)
products_bought = models.ManyToManyField(Product)
Я не думаю, что унаследую модель User
, лучше буду использовать собственный UserProfile
- оставив только модель contrib.auth
. С помощью специальной модели UserProfile
вы можете настроить базовую модель профиля пользователя, которая может быть частью всех ваших типов пользователей.
Просто взглянув на нее быстро, я тоже внимательно изучит любые модели, в которых повторяются все те же поля (например, две последние модели Принцип
и Администратор
). Сочетание встроенных групповых функций с идеей профиля пользователя может сделать то, что вы ищете.
Пожалуйста, подумайте, что происходит в модели данных, когда Координатор становится Принципалом. Я бы вообще не использовал наследование в этом случае. Пожалуйста, пересмотрите предложение предыдущего автора «Объединение встроенных групповых функций с идеей профиля пользователя может дать то, что вы ищете».
Недавно я перешел на использование моделей, наследуемых от contrib.auto.models.User. Мое общее наблюдение состоит в том, что в теории они великолепны, но иногда они не обрабатываются автоматически, как полагается.
Я думаю, ваше решение относительно наследования и OneToOne сводится к следующему:
-ИЛИ-
Если вы этого не видели, в блоге Скотта Бархэма есть отличная статья о наследовании пользователя, а также о создании настраиваемой серверной части, чтобы убедиться, что ваш настраиваемый объект возвращается - Расширение пользователя Django .
Кроме того, представляет интерес будет поле AutoOneToOne, предоставленное django-раздражает . Здесь это своего рода гибрид двух подходов - наследования не происходит, но Django заботится о создании соответствующего OneToOneField, если его нет.
Кроме того, thornomad действительно имеет смысл по поводу избыточности в ваших моделях. Вы можете легко реализовать абстрактный класс, чтобы очистить его таким образом (при условии, что вы выполняете OneToOne вручную):
class BaseExtendedUser(models.Model):
user = models.OneToOneField(User, blank=True, related_name='profile')
landline = models.CharField(blank=True, max_length=20)
mobile = models.CharField(blank=True, max_length=20)
created_by = models.ForeignKey(User, editable=False, blank=True, related_name="created_users")
modified_by = models.ForeignKey(User, editable=False, blank=True, related_name="modified_users")
class Meta:
abstract = True
class Administrator(BaseExtendedUser):
province = models.ForeignKey(Province)
class Principal(BaseExtendedUser):
branchoffice = models.ForeignKey(BranchOffice)
Нужны ли вам объекты ваших пользовательских классов, чтобы действовать как auth.User где угодно? Это будет наиболее очевидная причина использовать наследование вместо OneToOne. Одним из плюсов подхода OneToOne может быть простота перехода на другую модель пользователя, если это вызывает беспокойство.
Настоящая проблема, которую я вижу в том, что у вас есть выше (любым методом), заключается в том, что нет похоже, что-то мешает вам иметь объект-участник и объект-администратор совместно с одним и тем же пользователем. OneToOneField может гарантировать только однозначное соответствие между любыми двумя отношениями.