M
Спасибо. Ушел курить доки.
Size: a a a
2018 December 18
DK
Главное в транзакции не делать Task.start, тогда rollback не откатит инсерты
AV
и если вручную идти через Repo.transaction(fn -> end), то не стоит забывать о ручном вызове Repo.rollback.
а то после Multi у меня был баг, что внутри транзакции был with, который возвращал error, но не вызывал rollback.
в результате Repo.transaction возвращало {:ok, {:error, _}} как ни в чем не бывало
а то после Multi у меня был баг, что внутри транзакции был with, который возвращал error, но не вызывал rollback.
в результате Repo.transaction возвращало {:ok, {:error, _}} как ни в чем не бывало
K
Denis Kharchuk
Главное в транзакции не делать Task.start, тогда rollback не откатит инсерты
разве это не на уровне БД ? если делать Task.async() |> Task.await() должно же работать
DK
С Task.async() |> Task.await() не тэстил но с Task.start точно не будет работать
AV
Task.start в принципе лучше не юзать
DK
Если я не жду результат то почему бы и нет
AV
AV
По сути для более чистого cleanup процессов
AV
Но это конечно достаточно edge case
K
Denis Kharchuk
Если я не жду результат то почему бы и нет
ну там ты не можешь гарантировать, что попадет запрос в транзакцию. поэтому и не откатывает
K
Task.start в принципе лучше не юзать
почему ?
AV
почему ?
Выше скинул ссылку на пост
K
тут очень сложный вопрос использования. Task.start очень полезная функция, но нужно знать что именно делается в нем и как он поведет себя в случае чего.
K
даже в доках написано, чо это сделано для различных side-effects, когда не важен результат действия
AV
Да да, это все применимо и к task.supervisor.start_link.
K
ну к стати в плане использования Task.start/1 в работе с БД - соглашусь. там может все пойти сильно не так в случае отмирания ecto супервизора.
AV
в таком случае Task.start_link по-идее по цепочке должен тоже умереть, если ecto.supervisor убился
AV
я думаю бОльшая проблема с Task внутри транзации - не понятно как их rollback делать
AV
например база выкинула exception во время коммита транзакции