Окей, приведу пример. Есть эндпоинт, который создает stickerpack, также есть

эндпоинт, который создает favorite для конкретного юзера, который ссылается на stickerpack. При удалении stickerpack должны удалиться и всего его favorite, нужна ли здесь транзакция? А что если не проекте куча таких примеров, всё обмазать транзакциями?)

cascade

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

Вопрос, а нужна ли тебе здесь консистентность? Ну соответственно нужна или нет транзакция.

Нет, это каскадное удаление через внешний ключ на уровне БД. Транзакции тут не при чём

Для удаления stickerpack я иду в коллекцию stickerpacks и удаляю его там, после я иду в коллекцию favorties и подчищаю там. Все это в MongoDb. Может быть я не внимателен, но я не заметил возможность удалить документы одновременно в двух коллекциях, кроме как использовать транзакцию.

Я не знаю насчёт Монги, но в PostgreSQL внешнему ключу можно задать свойство ON DELETE CASCADE - и связанные данные автоматически будут подчищаться

Не удалять ничего, а помечать hidden=true

И это всё будет в рамках одного запроса, а что в случае неудачи? Они либо подчищаются все вместе, либо нет?

Это не очень хорошая практика, когда что-то неявно удаляется

Всё в рамках одного запроса. Атомарностью занимается база данных

Каскадное удаление на уровне БД - это стандартная практика. Удалите несколько десятков тысяч данных из таблицы - увидите, как быстро это сделается. Потому что будет всего лишь 1 запрос, а связи выпилит сам PostgreSQL

Да в монге же нет форенжкей. Она точно в какой-то момент будет неконсистентной. Так что забей на транзакции в ней и сделай джобы, которые периодически будут чистить данные. А сюда ещё накладываются эффекты кластера монги, что запись в один, а чтение в другом экземпляре монги. В общем делай как проще.

Ну вот и я вижу два путя: брать транзакцию и терпеть или запускать джобу и следить за чистотой коллекции

1. Следить за чистотой. 2. Удалять что можешь без транзакций.

foreign key читается как форин ки

Но в случае с insert (вставить несколько сущностей по разным коллекциям) такое уже не прокатит ведь и придется брать транзакцию и работать или также формируют джобы и досовывают то, что решило не засунуться?

Do you speak English? Дую, но xy#в@ :)

Так в монге судя по документации есть транзакции. Так что добавление делай в транзакции.

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

а я всегда как форэйн произношу 😅

Когда более одной коллекции меняешь - транзакция. Это мой финальный совет :)

я вас понял, спасибо)

статусы и в асинхроне двигать статусы по каждой операции

Не совсем понимаю о чем речь)

Выставляешь на удаление стикерпака и фаворитс флаги в отдельную коллекцию. Выставляешь воркер который по таймингу считывает статус у таких записей и удаляет записи:)

Понял, спасибо, Вы таким способом избегаете использование транзакций, когда надо менять две коллекции атомарно?

Ну я лишь способ назвал избежания. Еще бы поискал варианты, но легче транзакцию в монге сделать кажись

Ну способ, валидный в целом, в данном случае, согласен

Это он тебе асинхронный подход предлагает затащить. Это валидный вариант для долгих задач, типа отчёт построить. Но кажись это не твое.

Такой способ не избавляет от транзакции. Или во всяком случае не позволяет ее откатить в случае неуспеха.

например?

Ты удалил в нескольких коллекциях, потом ошибка... Часть данных не удалена. Те что не удалены уже не вернуть...

какая ошибка, не пойму…

Ну например сеть пропала.

на каком этапе, на клиентском запросе?

Воркер твой потерял сеть, пока удалял... Часть данных удалил, а часть нет. Стикер Пак удалил, а стикеры нет.

Если сеть пропала, при восстановлении сети статус подхватиться и завершит удаление второй части. Ну я не знаю насколько это критично вернуть такую транзакцию