Я прочитал документы: https://docs.djangoproject.com/en/3.0/topics/db/transactions/
Но мне не ясно, может ли транзакция охватить HTTP-запросы.
Идея состоит в том, достаточно просто:
- пользователь отправляет форму
- , затем
- открывает транзакцию
- сохраняет данные
- представляет пользователю с помощью формы подтверждения
- пользователь затем подтверждает или отменяет
- бэкэнд, затем фиксирует подтверждение или откатывается при отмене
Основная проблема заключается в что транзакция открывается по HTTP-запросу, затем ожидается ответ пользователя (если я не получу его, я думаю, что по истечении определенного времени мы откатимся), и когда он приходит ко второму HTTP-запросу, транзакция фиксируется.
Я не вижу ничего такого, что могло бы быть использовано в документах, и ничего не нашел в Интернете. Все же это поразило бы меня как довольно обычный случай использования. Он возникает главным образом из-за того, что представление является сложным, включает в себя множество моделей и отношений, и самый простой (почти только разумный или разумный) способ изучения воздействия представлений состоит в том, чтобы сохранить все эти данные и затем изучить влияние. Это прекрасно работает, как это происходит, но я до сих пор был вынужден принять решение об отмене или коммите в одном запросе при обработке формы. Теперь я хотел бы отослать свой анализ обратно пользователю и запросить ОК, прежде чем я сделаю коммит!
Мне нужно сделать это, второй запрос должен знать, к какой транзакции относится подтверждение, и определить, открыта ли эта транзакция, а затем зафиксировать ее или откатить. Это добавляет целый уровень идентификации транзакции, который я не вижу в Django документах.
Поддержка базы данных:
Интересно Postgresql может поддерживать это, если вся транзакция принадлежит одному сеансу (соединение с базой данных), как я подозреваю, что другие базы данных делают , Таким образом, это означает, что он может работать только в том случае, если сохранение выполняется постоянным демоном, который может начать транзакцию и продолжать работу до тех пор, пока транзакция не будет подтверждена и зафиксирована или откатана.
Что поднимает вспомогательный вопрос о том, предоставляет ли Django такую возможность. Я подозреваю, что нет, увы. Я подозреваю, что постоянные работники являются доменом uWsgi и / или Celery. И постоянный демон, который удерживает соединение с базой данных в ожидании запроса подтверждения, я подозреваю, называется диспетчером транзакций.
И поэтому этот вопрос действительно становится более кратким: существует ли простой / канонический способ реализации менеджера транзакций для Django.