Как автоматически создавать расширяющие модели для модели User?
Всем привет.
Расширил модель User, привязав к ней one-to-one модель Profile.
Регистрацию сделал через built-in-forms регистрация.
Нужно, чтобы при регистрации пользователя создавалась пустая модель Profile, привязанная к модели User. Сейчас при регистрации данная модель не создается.
Правильнее всего так вообще не делать (расширять модель пользователя профилем). Гораздо лучше перезагрузить стандартную модель пользователя собственной моделью с нужным набором полей. Одна запись в таблице вместо двух, ничего лишнего, сплошные профиты.
В документации на этот счет сказано так, что если нет жестких требований к скорости работы, то приоритетней расширить модель, нежели заменить стандартную своей.
Terras: глупости какие. Как это — "приоритетней"? Что за критерий такой?
Единственная сложность, которая может быть — если Вы используете старые (которым больше 3 лет... ну или криво написанные) приложения, модели которых жёстко ссылаются на django.contrib.auth.models.User. Но это отмазка слабая, я считаю: старым и криво написанным приложениям в любом случае доверять не стоит, безотносительно того, своя у Вас пользовательская модель или стоковая.
Одна модель лучше, чем несколько. Вы сами выберите, какие поля нужны. Вам не придётся создавать обработчики сигналов, которые, к слову, в сообществе не очень приветствуются ввиду своей неочевидности. Да и менеджер можно не перегружать, если Вы не удаляете "дефолтные" поля (если удаляете, то свой менеджер лучше написать).
В общем, моя рекомендация — не следовать мануалам пятилетней давности.
Think carefully before handling information not directly related to authentication in your custom User Model.
It may be better to store app-specific user information in a model that has a relation with the User model. That allows each app to specify its own user data requirements without risking conflicts with other apps. On the other hand, queries to retrieve this related information will involve a database join, which may have an effect on performance.
Terras: ну, хозяин-барин. Я бы, правда, сказал, что такие замечания отдалённо имеют смысл в двух случаях:
а) если Вы пишете подключаемые приложения и распространяете их отдельно от проекта. На pypi выкладываете
б) логика приложения подразумевает, что у пользователя может быть несколько абсолютно разных профилей с разным набором полей. Так бывает, хоть и достаточно редко.
В остальных случаях программист сам знает, какие данные ему нужны и где (и, соответственно, в его интересах не допускать конфликтов) эти "профили" — лишнее усложнение.
