Django: можно ли открыть транзакцию, запросить у пользователя подтверждение, а затем зафиксировать транзакцию, если она подтверждена, или откатиться

Я прочитал документы: https://docs.djangoproject.com/en/3.0/topics/db/transactions/

Но мне не ясно, может ли транзакция охватывать HTTP-запросы.

Идея достаточно проста:

  1. пользователь отправляет форму
  2. backend then
    1. opens a transaction
    2. сохраняет данные
    3. представляет пользователю форму подтверждения
    4. затем пользователь подтверждает или отменяет
  3. бэкэнд затем фиксируется при подтверждении или откатывается при отмене

Основная проблема заключается в том, что транзакция открывается по HTTP-запросу, затем ожидается ответ пользователя (если он никогда не получен, я думаю, по истечении времени мы откатимся), и когда он поступит на второй HTTP-запрос, транзакция преданный идее.

Я не вижу ничего, описывающего такой вариант использования в документации, и ничего не нашел в сети. Тем не менее, это может показаться мне довольно обычным вариантом использования. Это возникает в первую очередь из-за того, что представление является сложным, включает в себя множество моделей и отношений, и самый простой (почти единственный разумный или разумный) способ изучить влияние представленных материалов - это сохранить все их, а затем изучить влияние. Это прекрасно работает, но до сих пор меня заставляли принимать решение о фиксации или откате в одном запросе при обработке формы. Теперь я хотел бы передать свой анализ пользователю и попросить его подтвердить, прежде чем я сделаю коммит!

Мне кажется, что второй запрос должен знать, к какой транзакции относится подтверждение, и определить, открыта ли эта транзакция, а затем зафиксировать ее или откатить. Это добавляет целый уровень идентификации транзакции, который я не вижу в документации Django.

Поддержка базы данных:

Интересный Postgresql может поддерживать это, пока вся транзакция принадлежит одному сеансу (подключению к базе данных), как я подозреваю, что и другие базы данных. Таким образом, это означает, что он может работать только в том случае, если сохранение выполняется постоянным демоном, который может запустить транзакцию и продолжать работу до тех пор, пока транзакция не будет подтверждена и зафиксирована или откат.

Возникает дополнительный вопрос, предоставляет ли Django такую ​​возможность. Я подозреваю, что нет. Я подозреваю, что постоянные воркеры являются прерогативой uWsgi и / или Celery. И постоянный демон, который удерживает соединение с базой данных в ожидании запроса подтверждения, я подозреваю, называется менеджером транзакций.

И поэтому этот вопрос действительно становится более кратким: есть ли простой / канонический способ реализации диспетчера транзакций для Django.


django commit transactions rollback
person Bernd Wechner    schedule 17.01.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я не знаю ни одной библиотеки, которая бы сделала то, что вы сказали. Хотя как я буду решать эту проблему, после отправки формы я сохраню переменные в сеансе запроса и выполню необходимые проверки проверки БД, после чего пользователь может подтвердить, и транзакция может быть выполнена. В Django вы можете выполнять атомарные транзакции с помощью библиотеки транзакций 

from django.db import transaction

Это позволяет вам использовать @transaction.atomic декоратор или контекстную функцию в поле зрения

def viewfunc(request):
    # This code executes in autocommit mode (Django's default).
    do_stuff()

    with transaction.atomic():
        # This code executes inside a transaction.
        do_more_stuff()

Подробнее об этом можно прочитать в документации Django https://docs.djangoproject.com/en/3.0/topics/db/transactions/

person Harsh Nagarkar    schedule 17.01.2020
comment
Спасибо за предложение. Увы, вы затронули главную проблему, которую я исследую. То есть Django предоставляет ORM, который позволяет создавать богатый объектно-ориентированный вид постоянных (находящихся в базе данных) объектов. Самым преимуществом ORM является то, что мы можем легко и быстро выполнять много интересной работы с объектами. Причина выполнения этого в транзакции - сделать это временно, чтобы можно было оценить влияние и сделать откат. Короче говоря, в ORM можно выполнить много работы, которая не может быть выполнена одной только отправкой формы. - person Bernd Wechner; 18.01.2020
comment
О, и, как ни странно, вы рекомендуете прочитать документ, который я сказал в вопросе, который я читал. Также я знаю, как реализовать транзакции, завершенные одним HTTP-запросом. Задача состоит в том, чтобы иметь один диапазон HTTP-запросов, чтобы вы могли получать пользовательский ввод о том, следует ли выполнять фиксацию или откат. И я подозреваю, что для этого нужен менеджер транзакций, работающий как демон, который может удерживать соединение с базой данных открытым во время взаимодействия, и Celery может быть самым популярным и доступным способом сделать это, хотя я пока не могу найти канонический метод связи с запущенным Задача сельдерея, которая удерживает такую ​​транзакцию открытой. - person Bernd Wechner; 21.01.2020