Как изменить значение по умолчанию django модель User для установки моим потребностям?
На Maria DB вы используете mysql_install_db. В моем случае я использую переменную окружения для пути к данным, что означает, что mysqld должен не только знать, где через командную строку, но также и скрипт установки:
mysql_install_db --user=root --datadir=$db_datapath
4 ответа
Вместо того, чтобы напрямую изменять класс User или создавать подклассы, вы также можете просто изменить назначение существующих полей.
Для одного сайта я использовал поле «first_name» в качестве «публично отображаемого имени» пользователя и вставил его сокращенную версию в поле «username» (для использования в URL). Я написал настраиваемый бэкэнд аутентификации, чтобы люди могли входить в систему, используя свое «публичное имя» или свой адрес электронной почты, и я обеспечиваю уникальность обоих из них во время регистрации. Это прекрасно сочетается с другими многоразовыми приложениями и не вводит дополнительных таблиц или запросов.
Для другого сайта мне вообще не нужны были имена пользователей, а были только уникальные электронные письма. Чтобы удовлетворить потребность Django в уникальном имени пользователя, Я просто хешировал адрес электронной почты и использовал его в качестве имени пользователя (вам нужно кодировать хеш base64, чтобы сжать его до 30 символов). Пользовательский бэкэнд аутентификации, позволяющий вход по электронной почте.
Если бы обратная совместимость не была проблемой, я бы хотел внести множество улучшений в django.contrib.auth и модель User, чтобы сделать их более гибкими . Но вы можете многое сделать в рамках текущих ограничений, проявив немного творчества.
Я неправильно понял вопрос. Надеюсь, этот пост будет полезен кому-то еще.
#in models.py
from django.db.models.signals import post_save
class UserProfile(models.Model):
user = models.ForeignKey(User)
#other fields here
def __str__(self):
return "%s's profile" % self.user
def create_user_profile(sender, instance, created, **kwargs):
if created:
profile, created = UserProfile.objects.get_or_create(user=instance)
post_save.connect(create_user_profile, sender=User)
#in settings.py
AUTH_PROFILE_MODULE = 'YOURAPP.UserProfile'
Это будет создавать профиль пользователя каждый раз, когда пользователь будет сохранен, если он будет создан. Затем вы можете использовать
user.get_profile().whatever
Вот еще некоторая информация из документов
http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users
Модель пользователя Django структурирована очень разумно. Например, вы действительно не хотите разрешать использование произвольных символов в имени пользователя, и есть способы получить адрес электронной почты для входа , не взламывая изменения базовой модели.
Просто хранить дополнительную информацию вокруг учетная запись пользователя, Django поддерживает понятие профилей пользователей. Хотя вам не нужно полагаться на встроенную поддержку, чтобы справиться с этим, это соглашение, которое обычно соблюдается, и оно позволит вам хорошо играть с многоразовыми приложениями Django, которые плавают в эфире. Для получения дополнительной информации см. здесь .
Если вы действительно хотите изменить базовую модель User, но при этом «поиграть» с многоразовыми приложениями, которые полагаются на нее, вы открываете что-то вроде ящика Пандоры. . Разработчики делают базовые предположения о том, как структурирована основная библиотека, поэтому любые изменения могут вызвать неожиданный сбой. Тем не менее, вы можете исправить изменения базовой модели или создать локальную ветвь копии Django. Я бы не одобрил последнее и рекомендовал бы первое только в том случае, если вы знаете, что делаете.
Вы сталкиваетесь с дилеммой, у которой действительно есть два решения, если вы стремитесь избежать уже упомянутой настройки на основе профиля.
- Измените пользователя
- Напишите класс
CustomUser, создав подклассUserили скопируйте его функциональность.
Последнее предложение означает, что вам придется реализовать некоторые вещи, которые Пользователь делает это автоматически вручную, но мне интересно, так ли это плохо, как кажется, особенно если вы в самом начале своего проекта. Все, что вам нужно сделать, это переписать промежуточный класс и некоторые декораторы.
Конечно, я не думаю, что это принесет вам что-то такое, чего я не получу, кроме того, что ваш проект не должен ' t сломается, если вы svn update ваш django. Это может избежать некоторых проблем совместимости с другими приложениями, но я предполагаю, что большинство проблем будет существовать в любом случае.