AA
Тогда поидее в одной транзакции должно быть, а то малоли что там произойдёт между двумя запросами
Size: a a a
2020 March 17
IB
В постгре хотябы количество удаленных строк
Ecto так тоже умеет, через
delete_all/2, если база данных поддерживаетx
любое неатомарное действие с бд надо бы в транзакцию оборачивать
ŹR
Вроде как селекты транзакцией не гарантируют ничего
ŹR
Но в этом я не очень шарю честно говоря
ŹR
Ecto так тоже умеет, через
delete_all/2, если база данных поддерживаетДа, но это считай надо код по другому писать
x
ну есть такая штука как уровни изоляции транзакций - можно прочесть то, что уже было изменено, но еще не закомичено
ŹR
ну есть такая штука как уровни изоляции транзакций - можно прочесть то, что уже было изменено, но еще не закомичено
Да, в эту сторону работает
ŹR
Но в другую как раз нет. Т.е. если ты прочитал селектом а потом час думаешь, то другой сможет удалить в это время
ŹR
И ты в транзакции как бы тоже попробуешь удалить, но без эффекта. Получается транзакция не имеет смысла
ŹR
Вот если ты обновил к примеру сперва, то запись по идее заблочится от параллельных действий до конца коммита
x
да, соглашусь с Вами
ŹR
Но может там что-то можно где-то настроить
x
select for update - но лучше бы не надо так делать
AN
Есть же транзакции с локом на чтение
ŹR
Короче лучше один раз из миллиона на race condition вернуть вместо 404 500
ŹR
Чем запариваться по этому поводу
AG
Если гарантия нужна то используй serializable в постгресе, городить ничего не надо в этих случаях.
AG
На всякий ссылка на оффдоку
https://www.postgresql.org/docs/9.5/transaction-iso.html
https://www.postgresql.org/docs/9.5/transaction-iso.html
VS
с полной сериализацией
надо быть готовым к перезапуску транзакции,
так что городить все равно
придется
надо быть готовым к перезапуску транзакции,
так что городить все равно
придется