Я сейчас сделал так. Передаю в сервис некий интерфейс TransactionManager с Begin(), Commit(), Rollback() - это чтобы от СУБД не зависеть. В сервисе значит открываю транзакцию, и полученный *sql.Tx кладу в ctx.WithValue(). В хранилище достаю из контекста транзакцию и работаю уже с ней. Это не сильно криво?
а это все зачем?
Этот вопрос уже несколько раз точно тут задавался. Кто-то считает, что так ок Кто-то ( я к примеру) считает, что транзакцию не надо пихать в контекст
Я плавно переползаю из MongoDB, в котором транзакций нет, в sql. И изврат этот для того, чтобы в сервисе не было зависимости на sql.DB. Но чую что-то перемудрил.
а как связаны транцакции с зависимостями?
Подобные вопросы возникают, когда надо одну транзакцию на несколько репозиториев размазать
в монго нет транзакций? как так
вообще, есть, но относительно недавно
1. Использую go-kit. Flow: транспорт -> endpoint -> сервис. Сервис уже работает с бизнес-логикой. Сервис может работать с несколькими репозиториями (хранилищами). 2. В такой схеме я подумал, что на один внешний запрос мне достаточно одну транзакцию. Иногда может быть несколько. 3. Подумал что с текущим flow логично транзакции организовывать внутри сервиса, ибо может быть вызов нескольких хранилищ. 4. При создании сервиса ему тогда надо передать какую-то информацию о соединении с БД, желательно интерфейс, чтобы от СУБД не зависеть. Придумал передать как раз TransactionManager. 5. В хранилище, ибо их несколько, надо передавать уже открытую транзакцию. Ну вот как-то из этого всего слепилось.
Тока запилили, и то под давлением. Там считается, что сохранение одного документа должна быть атомарная операция и транзакции тебе не нужны.
с 4.2 вроде. а уже 5+
ваши вкусы очень специфичны, коллега ничем вам не помогу - для меня все описанное какая-то жуть
ну, да, я так и сказал 🙂
sql.DB — это уже абстракция от СУБД
Обсуждают сегодня