Разница в последовательности запросов, сгенерированных в Django и Postgres для select_for_update
Я столкнулся со странной ситуацией, где последовательность запросов, зарегистрированных в Django и Postgres, отличается при использовании select_for_update()
внутри transaction.atomic()
.
В основном у меня есть ModelForm
, где я проверяю cleaned_data
на базу данных для дублирования запроса. А затем в режиме создания представления form_valid()
я сохраняю экземпляр. Чтобы выполнить операцию внутри одной транзакции, я переопределяю метод post()
и обертываю эти два вызова метода внутри transaction.atomic()
.
Здесь код для того, что я сказал выше:
# Form
class MenuForm(forms.ModelForm):
def __init__(self, *args, **kwargs):
user_id = kwargs.pop('user_id', None)
super(MenuForm, self).__init__(*args, **kwargs)
def clean(self):
cleaned_data = super(MenuForm, self).clean()
dish_name = cleaned_data.get('dish_name')
menus = Menu.objects.select_for_update().filter(user_id=self.user_id)
for menu in menus:
if menu.dish_name == dish_name:
self.add_error('dish_name', 'Dish already exists')
return cleaned_data
return cleaned_data
# CreateView
class MenuCreateView(CreateView):
form_class = MenuForm
def get_form_kwargs(self):
kwargs = super(MenuCreateView, self).get_form_kwargs()
kwargs.update({'user_id': self.request.session.get('user_id')})
return kwargs
def form_valid(self, form):
user = User.objects.get(id=self.request.session.get('user_id'))
form.instance.user = user
return super(MenuCreateView, self).form_valid(form)
def post(self, request, *args, **kwargs):
form = self.get_form()
with transaction.atomic():
if form.is_valid():
return self.form_valid(form)
else:
return self.form_invalid(form)
Теперь предположим, что я запускаю два запроса одновременно, чтобы создать меню с одним и тем же блюдом. Я ожидаю, что второй запрос потерпит неудачу. Но они оба проходят. Похоже, вторая транзакция не видит изменений, выполненных в предыдущей транзакции. Из-за этого общая сумма menus
остается неизменной как в транзакции, возвращаемой select_for_update()
.
Учитывая, что уровень изоляции по умолчанию Postgres равен READ COMMITTED
, я ожидаю, что изменения будут видимыми. Итак, я попытался выполнить регистрацию запросов, чтобы увидеть, что COMMIT; увольняется в нужное время. Здесь журнал запросов django и postgres:
Журнал Django:
SELECT "menu"."id", "menu"."dish_id", "menu"."dish_name" FROM "menu" WHERE ("menu"."dish_name" = "Test Dish") FOR UPDATE; args=("Test Dish")
INSERT INTO "menu" ("dish_id", "dish_name") VALUES (2, "Test Dish") RETURNING "menu"."id"; args=(2, "Test Dish")
SELECT "menu"."id", "menu"."dish_id", "menu"."dish_name" FROM "menu" WHERE ("menu"."dish_name" = "Test Dish") FOR UPDATE; args=("Test Dish")
INSERT INTO "menu" ("dish_id", "dish_name") VALUES (2, "Test Dish") RETURNING "menu"."id"; args=(2, "Test Dish")
Журнал Postgres:
<2016-03-18 17:55:46.176 IST 0 2/31 56ebf3ca.aac0>LOG: statement: SHOW default_transaction_isolation
<2016-03-18 17:55:46.177 IST 0 2/32 56ebf3ca.aac0>LOG: statement: SET TIME ZONE 'UTC'
<2016-03-18 17:55:46.178 IST 0 2/33 56ebf3ca.aac0>LOG: statement: SELECT t.oid, typarray
FROM pg_type t JOIN pg_namespace ns
ON typnamespace = ns.oid
WHERE typname = 'hstore';
<2016-03-18 17:55:46.182 IST 0 2/34 56ebf3ca.aac0>LOG: statement: BEGIN
<2016-03-18 17:55:46.301 IST 0 3/2 56ebf3ca.aac1>LOG: statement: SHOW default_transaction_isolation
<2016-03-18 17:55:46.302 IST 0 3/3 56ebf3ca.aac1>LOG: statement: SET TIME ZONE 'UTC'
<2016-03-18 17:55:46.302 IST 0 3/4 56ebf3ca.aac1>LOG: statement: SELECT t.oid, typarray
FROM pg_type t JOIN pg_namespace ns
ON typnamespace = ns.oid
WHERE typname = 'hstore';
<2016-03-18 17:55:46.312 IST 0 3/5 56ebf3ca.aac1>LOG: statement: BEGIN
<2016-03-18 17:55:46.963 IST 0 3/5 56ebf3ca.aac1>LOG: statement: SELECT "menu"."id", "menu"."dish_id", "menu"."dish_name" FROM "menu"
WHERE ("menu"."dish_name" = "Test Dish") FOR UPDATE
<2016-03-18 17:55:46.964 IST 0 2/34 56ebf3ca.aac0>LOG: statement: SELECT "menu"."id", "menu"."dish_id", "menu"."dish_name" FROM "menu"
WHERE ("menu"."dish_name" = "Test Dish") FOR UPDATE
<2016-03-18 17:55:47.040 IST 23712 3/5 56ebf3ca.aac1>LOG: statement: INSERT INTO "menu" ("dish_id", "dish_name") VALUES (2, "Test Dish")RETURNING "menu"."id"
<2016-03-18 17:55:47.061 IST 23712 3/5 56ebf3ca.aac1>LOG: statement: COMMIT
<2016-03-18 17:55:47.229 IST 23713 2/34 56ebf3ca.aac0>LOG: statement: INSERT INTO "menu" ("dish_id", "dish_name") VALUES (2, "Test Dish")RETURNING "menu"."id"
<2016-03-18 17:55:47.231 IST 23713 2/34 56ebf3ca.aac0>LOG: statement: COMMIT
Postgres.conf:
max_connections = 100
log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_line_prefix = '<%m %x %v %c>'
log_statement = 'all'
Как вы можете видеть, порядок запросов SELECT и INSERT не одинаковый в обоих журналах. Я не могу понять, почему это произойдет. Кроме того, если вы заметили, session_id для запросов SELECT в журнале Postgres отличается. Может ли это объяснить что-то здесь?
И если это ожидаемое поведение, как я могу решить основную проблему здесь? Избегайте одновременных запросов INSERT на основе существующей записи.
UPDATE
Я не упомянул, что фактическая логика для игнорирования дублированного меню основана не только на имени тарелки. Приведенный выше пример упрощен.
Учитывая модель меню как:
class Menu:
user_id = models.IntegerField()
dish = models.ForeignKey(Dish)
order_start_time = models.DateTimeField()
order_end_time = models.DateTimeField()
Фактическая логика выглядит следующим образом:
- Извлеките все меню с помощью
dish_name
из db.
- Отметьте
order_start_time
и order_end_time
для всех этих меню и посмотрите, не пересекаются ли какие-либо из них с order_start_time
и order_end_time
для нового меню. Если конфликт найден, избегайте добавления.
Итак, мы можем добавить два меню для блюда - d1
, имеющих окно заказа - [9am-10am]
и [2pm-3pm]
.
Ответы
Ответ 1
Редакция:
Как заставить Django проверять перекрывающиеся резервирования?
Можно добавить специальный метод для модели validate_unique
:
from django.db import models
from django.core.validators import ValidationError
from django.forms.forms import NON_FIELD_ERRORS
class Dish(models.Model):
name = models.CharField('Dish name', max_length=200)
class Menu(models.Model):
user_id = models.IntegerField()
dish = models.ForeignKey(Dish)
order_start_time = models.DateTimeField()
order_end_time = models.DateTimeField()
def validate_unique(self, *args, **kwargs):
# call inherited unique validators
super().validate_unique(*args, **kwargs) # or super(Menu, self) for Python2.7
# query if DB already has object with same dish
# and overlapping reservation
# [order_start_time, order_end_time]
qs = self.__class__._default_manager.filter(
order_start_time__lte=self.order_end_time,
order_end_time__gte=self.order_start_time,
dish=self.dish,
)
# and this object is not the same we are working with
if not self._state.adding and self.pk is not None:
qs = qs.exclude(pk=self.pk)
if qs.exists():
raise ValidationError({
NON_FIELD_ERRORS: ['Overlapping order dates for dish'],
})
Давайте попробуем его в консоли:
from core.models import *
m=Menu(user_id=1, dish_id=1, order_start_time='2016-03-22 10:00', order_end_time='2016-03-22 15:00')
m.validate_unique()
# no output here - all is ok
m.save()
print(m.id)
8
# lets add duplicate
m=Menu(user_id=1, dish_id=1, order_start_time='2016-03-22 12:00', order_end_time='2016-03-22 13:00')
m.validate_unique()
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/Users/el/tmp/hypothesis_test/menu/core/models.py", line 29, in validate_unique
NON_FIELD_ERRORS: ['Overlapping order dates for dish'],
django.core.exceptions.ValidationError: {'__all__': ['Overlapping order dates for dish']}
# excellent! dup is found!
# But! Django helps you find dups but allows you to add them to db if you want it!
# It responsibility of your application not to add duplicates.
m.save()
print(m.id)
9
Как быть уверенным, что noboby может добавить дубликат?
В этом случае вам нужно сделать CONSTRAINT на уровне базы данных.
В консоли PostgreSQL:
CREATE EXTENSION btree_gist;
-- our table:
SELECT * FROM core_menu;
id | user_id | order_start_time | order_end_time | dish_id
----+---------+------------------------+------------------------+---------
8 | 1 | 2016-03-22 13:00:00+03 | 2016-03-22 18:00:00+03 | 1
9 | 1 | 2016-03-22 15:00:00+03 | 2016-03-22 16:00:00+03 | 1
DELETE FROM core_menu WHERE id=9; -- we should remove dups before adding unique constraint
ALTER TABLE core_menu
ADD CONSTRAINT core_menu_exclude_dish_same_tstzrange_constr
EXCLUDE USING gist (dish_id WITH =, tstzrange(order_start_time, order_end_time) WITH &&);
Теперь давайте создадим дублирующий объект и добавим его в db:
m=Menu(user_id=1, dish_id=1, order_start_time='2016-03-22 13:00', order_end_time='2016-03-22 14:00')
m.save()
Traceback (most recent call last):
File "/Users/el/tmp/hypothesis_test/venv/lib/python3.5/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
psycopg2.IntegrityError: ОШИБКА: конфликтующее значение ключа нарушает ограничение-исключение "core_menu_exclude_dish_same_tstzrange_constr"
DETAIL: Key (dish_id, tstzrange(order_start_time, order_end_time))=(1, ["2016-03-22 13:00:00+00","2016-03-22 14:00:00+00")) conflicts with existing key (dish_id, tstzrange(order_start_time, order_end_time))=(1, ["2016-03-22 10:00:00+00","2016-03-22 15:00:00+00")).
Отлично!
Теперь данные проверяются на уровне программ и db.