Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Как хранить пользователя в одной таблице ? #34

Open
mcd-php opened this issue Dec 17, 2015 · 2 comments

Comments

@mcd-php
Copy link
Contributor

mcd-php commented Dec 17, 2015

Сейчас пользователь у меня хранится в ТРЁХ таблицах: родная auth_user, django_ulogin_uloginuser и myproject_user_info из примера customize/models.py

Django умеет переопределять модель пользователя и теоретически я могу слить вместе auth_user и myproject_user_info полностью сам, но как мне заставить django_ulogin писать в неё же свои данные ?

Цель - иметь доступ ко всей информации о пользователе в одной модели, которая автоматически берётся из базы и подставляется в разные места, в том числе в контексты шаблонов. Избегнуть необходимости делать три запроса к БД или JOIN на каждый веб-запрос.

P.S. Пишу в Issues а не в личное письмо, т.к. ответ будет полезен в общей документации.

@marazmiki
Copy link
Owner

Похоже, на текущий момент сделать это красиво штатными способами не получится, поскольку использование модели ULoginUser захардкожены. Вот, например, во вьюхе:

Может, есть ещё какие-то места, про которые я сходу не вспомнил.

Что тут посоветовать, кроме того, чтобы отнаследоваться от этой CBV и полностью повторить логику, переименовав модель — не знаю. Разве что переписывать django-ulogin :) Добавить поддержку swappable-модели по типу джанговской, потребовать для неё наличия определённых полей типа provider и identity и всё.

Вьюхи даже менять не придётся, достаточно будет дописать ближе к началу файла что-то типа

ULoginUser = get_model(settings.ULOGIN_AUTH_MODEL)

и само схватится. Вопрос упирается во время

@mcd-php
Copy link
Contributor Author

mcd-php commented Dec 17, 2015

PyCharm творит чудеса, даже Community Edition - все использования как на ладони, если только нету косвенных, не по имени.

Сейчас меня сдерживает только то что мои изменения будут ломать обратную совместимость с давними установками django_ulogin (мой проект ещё не был опубликован, живых данных в нём нет), и что я не знаю как сделать это наиболее Pythonic способом, чтобы для всех было привычно и интуитивно.

Ещё могут столкнуться имена колонок, я во всех своих проектах ставлю на колонки префиксы (не location.address_id, а location.lctn_address_id), при поиске вхождений или таскании колонок по разным таблицам можно разом поменять везде, идею взял у Википедии при закладке первого коммерческого проекта.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants