Вы никогда не задумывались на что делать ссылку в модели, если надо привязать её к пользователю? К User или Profile (любой модели которая выполняет роль "профиля")? Этот вопрос, конечно, справедлив для тех проектов. где есть необходимость в профиле как таковом, иначе ссылка на User и все дела.
Я для себя какое-то время назад решил, что Profile выгоднее. Небольшой анализ всё же показал, что всё зависит от конкретного случая и вариантов использования результирующей модели.
Рассмотрим ситуацию, когда основная информация для работы приложения, относящаяся к пользователю, как раз хранится в профиле. Тогда при ссылке на User нужно будет каждый раз "дотягивать" ещё и профиль. Не очень удобно, да и накладно к тому же. Если же завязаться на профиль, то всё становится прозрачнее и оптимальнее. Тем более, если профиль реализован через наследование от User, то вообще разницы для клиентского кода модели не будет - профиль для него прозрачно становится юзером. Хочу лишь отметить, чтобы прозрачность была полной, не забудьте у профиля переопределить менеджер либо на UserManager, либо на его наследника с дополнительным функционалом.
В своих проектах я именно так и поступаю. Например в этом блоге посты (автор) связаны с профилем.
Если предполагается что приложение. которое вы разрабатываете будет использоваться как библиотечный код в неизвестном окружении, то завязка на профиле может оказаться лишней и ненужной. Но это уже конечно другое приложение, и изначальное допущение, что "основная информация для работы в приложении, относящаяся к пользователю, как раз хранится в профиле" уже не действует. Иначе профиль просто необходим, а значит на него можно ссылаться.
Этим вопросом в своё время задался не только я. Единожды я наткнулся на схожее обсуждение в django-users. Где Малкольм высказывает свои интересные мысли на этот счет.
PS: сегодня в 12 часов у нас в Яндексе состоится Джанго-спринт. Приходите, будет очень интересно. Я конечно же тоже буду. Но не надолго - дерби как никак в 4 часа...

А есть ещё один оригинальный способ: можно пропатчить модель пользователя, добавив туда недостающие поля. Такой подход можно увидеть в byteflow, например. Удобства подхода: * никаких конфликтов с профилем пользователя при интеграции в другой сайт * никаких плясок с оптимизацией кол-ва запросов: все данные лежат в модели User
Да тоже вариант, но манки-патчинг не очень религиозно красив. И может конфлинкт с чем-то вызвать. Идея с наследованием профиля от юзера мне нравится больше. Она по сути также прозрачна как и модификация юзера самого, но более грамотно что-ли выглядит. Тем более, добавлять поля в
Userпроблематично, если приложение подключается к уже давно работающему проекту.Таки наследование может заменить механизм профилей? Там никаких граблей не вылазит?
Спасибо, как раз думал как именно вязать.
P.S.: после предпросмотра комментария, текст кнопки сохранить почему-то "Редактировать".
И время комментариев оно местами попутало. Спасибо должно быть в 21 с чем-то, а PS почти в 22.
Так, очевидно, время пишется GMT, но если сделать предпросмотр, то локальное.
Да. Вполне. Все грабли уже зарыты в землю:) Это в "Наследствах с особенностью" можно почитать.
"П
****ц позорище!"Простите.
Ох. Это вообще моя головная боль уже давно. Слетает то ли локаль, то ли ещё что-то. Не могу понять. И что самое обидное, что не всегда. Большую часть времени всё работает как надо. Буду разбираться дальше. Спасибо.
При условии что с наследованием моделей УЖЕ всё хорошо, смысла ставить FK на модель User совершенно никакого. Ведь можно прозрачно получать информацию и из Profile и User при этом оно сливается в единое целое избегая дополнительных запросов.
"Красота" одним словом :)
P.S.
Алекс, предпросмотр комментария так же сбился :/
А вот для этого можно пример:
Разобрался.
objects=UserManager()
Да. Если переопределить, то удобнее получается использование "профиля как юзера".
я, конечно, здесь никто, но имхо (имхо быдлокодера!) наследование профиля от пользователя - это надо сразу на http://community.livejournal.com/emo_coders/, потому как /me плакать, как только увидеть это.
Если сделать наследование то как заставить данный класс использоваться джангой например в request.user?
Нужно написать свой middleware и заменять им стандартный из auth