Django. Есть ли встроенный механизм пред-сохранения данных перед сохранением модели?

Question

[Vic Shóstak]

Доброго времени года!

Интересует вопрос: есть ли в Django (1.11/2.х) встроенный механизм пред-сохранения данных перед сохранением модели? Поясню. Например, есть модель, которая реализует форму заявки на наличие товара (поля: ФИО, телефон, почта, ID товара со страницы, связь с ID юзера).

Сложность в том, что для функционирования данного примера — нужен ещё и ID юзера, то есть данную заявку могут видеть все, но отправлять (сохранять) только зарегистрированные пользователи.

Так вот. Как сделать (штатными методами Django), чтобы данные из формы сохранялись в какой-нить Redis, приложение переходило на страницу логина, при успешной авторизации — доставало из Redis все данные + присваивало ID пользователя (который теперь есть) — только после этого сохранялось в БД (Postgres)?

Вопрос нубский, но никогда не сталкивался с подобной задачей.. поэтому, очень хотелось бы послушать best practice по этой теме, но буду рад и просто толковым комментариям. Спасибо! :)

Answer 1

[Сергей Горностаев]

Есть. Можно переопределить в модели метод save() и можно зарегистрировать обработчик сигнала pre_save. Но правильное решение - это показывать форму только авторизованным пользователям.

Comments

[Vic Shóstak]

Да, понимаю, что лучшее решение — это минимизация таких ситуаций, путём показа только того контента, который разрешен в данном инстансе :) Но, к сожалению, вводные именно такие (ведь, допустим, никто не хочет терять таких любопытных посетителей, особенно, если это касается е-коммерц).

Спасибо за ссылки. Не хотелось бы использовать сигналы, ибо анти-патерн. Поэтому пойду через переопределение save() у модели... тем более, что это даже проще, чем потом разбираться с "где какой сигнал, что делает и зачем?".

Я так понимаю, что алгоритм в save() будет такой:

0. получаем данные
1. если залогинен пользователь — сохраняем как обычно
2. если нет — записываем в сессию (а она вообще есть у анонима, кстати?!) все данные
3. переводим на страницу логина (где next параметром будет страница, например, с success сообщением)
4. аноним авторизируется
5. перекидываем его на страницу из next

Я верно мыслю или может лучше не в сессию, а Redis/RMQ?

[Сергей Горностаев]

Vic Shóstak, вы не сможете получить из save() доступа к запросу, а соответственно и сессии. Поэтому придётся сохранять куда-нибудь в другое место и думать, как связать сохранённое с пользователем, который потом залогинится.

[Roman K]

Vic Shóstak, переопределение save нужно делать только в исключительных ситуациях. Это крайне неочевидное поведение, которое невероятно сложно отследить, особенно, если кодовая база большая и не твоя. Сигналы куда наглядней и их легко отслеживать тем же django-debug-toolbar.

[Vic Shóstak]

Pavel Denisov, как понять "не в save, а во views"? То есть, надо всё делать не когда сохраняется модель, а когда с фронта прилетает POST из той формы? Или я не так понял? :)

Roman Kitaev, я читал как раз противоположную точку зрения, что именно использование сигналов делают путаницу и не прозрачны в больших проектах.. хм..

[Сергей Горностаев]

Vic Shóstak, сами разработчики Django в официальной документации рекомендуют сигналы.

[Roman K]

Pavel Denisov, Опять же, сигналы можно смотреть в DDT, save нет. Сигналы более гибкие. Был у меня проект, в котором надо было подсчитывать размер всех файлов юзера. Очевидно, каждый раз ходить по БД и пересчитывать без денормализации — самоубийство. При этом, моделей, содержащих всякие FileField, ImageField и других производных FileField было вагон и маленькая тележка. Я повесил всего 3 хэндлера, по 1 на каждый сигнал. post_init, pre_delete, post_save и внутри хэндлеров ходил по инстансам и смотрел, есть ли у инстанса производные FileField. Всё. Представь, сколько бы методов save мне пришлось переопределить.

Вот вся магия:

def get_sum_sizes(instance):
    """
    Суммирует размеры файлов инстанса (FileField, ImageField и любые
    производные FileField)
    """
    sized_fields = (f.attname for f in instance._meta.fields if isinstance(f, models.FileField))

    def get_size(field):
        f = getattr(instance, field)
        return f and f.size or 0
    return sum(get_size(f) for f in sized_fields)


@receiver(post_init)
def store_old_files_size(instance, **kwargs):
    """
    К инстансу, у которого есть атрибут клиники
    дописывается сумма байтов, занимаемых файлами инстанса
    """
    if getattr(instance, 'clinic_id', None) is None:
        return
    instance.__old_files_size = get_sum_sizes(instance)


@receiver(post_save)
def update_clinic_files_size(instance, created, **kwargs):
    if not created and not hasattr(instance, '__old_files_size'):
        return
    if created:
        instance.__old_files_size = 0

    clinic = getattr(instance, 'clinic', None)
    append = get_sum_sizes(instance) - instance.__old_files_size

    if append and clinic:
        Clinic.objects.filter(pk=clinic.pk).update(files_size=F('files_size') + append)


@receiver(pre_delete)
def update_clinic_files_size_delete(instance, **kwargs):
    """Удалённые файлы не занимают место"""
    if not hasattr(instance, '__old_files_size'):
        return

    clinic = instance.clinic
    subtract = get_sum_sizes(instance)
    if subtract:
        Clinic.objects.filter(pk=clinic.pk).update(files_size=F('files_size') - subtract)

[Vic Shóstak]

Pavel Denisov, то есть, для этой вьюхи (принимающей POST с формы) нужно будет установить, что-то типа декоратора @login_required и, по идее, всё автоматом где-то сохранится уже Джангой? Или там нет такого и после отправки на логин-форму — всё, что было на предыдущей странице — пропадает при возвращении?

[Vic Shóstak]

Pavel Denisov, короче говоря, не уповать на @login_required и проверять всё только во вьюхе после запроса?

[Vic Shóstak]

Pavel Denisov, а. Всё, теперь понял :) Иными словами, если навесить во вьюхе на def post() этот декоратор — запрос просто упадёт с 403 статусом для анонима?

Answer 2

[Артем Советников]

Я так понимаю вам надо:
1. Показать форму заявки незарегестрированному пользователю
2. Принять заявку через форму у этого пользователя и направить на страницу регистрации
3. После того как пользователь зарегестрировался, создать для него заявку в системе от его имени
Так?

1. Делайте сущность "ПредварительнаяЗаявка" аналогично вашей заявке и сохраняйте её в базу когда пользователь без авторизации её создаёт, зачем redis? Или вообще признак у заявки сделайте "Предварительная" и без привязки к пользователю её создавайте.
2. Далее после создания предварительной заявки, сохраняете идентификатор созданной предварительной заявки в сессию неавторизованного пользователя.
3. Как зарегестрировался пользователь, делаете из его предварительной заявки нормальную, её идентификатор будет в данных сессии пользователя.

Всё просто.