В рамках работы нескольких последовательных операций с sql источником на самом деле все не так сложно. Несколько последовательных вызовов к базе группируются и работают с одним и тем же курсором в одной транзакции, если нужно обеспечить механизм rollback. Принимают его в качестве опционального параметра.
Т.е. в слое сервисов должна порождаться транзакция, и пропихиваться в репозитории ? Или репозиторий должен содержать транзакционные методы, типа, утрирую, update_post_and_add_comment_and_update_user_and_notify ? Или же мы должны собирать аггрегат в классическом виде, и его сохранять полностью ?
P.S. не придираюсь ни в коем случае, тема мне очень интересна. За сам пост большое спасибо, +- к этому и пришли.
Боль слоя persistence и БД начинается с транзакциями, когда, например, 2 метода репозитория должны быть выполнены в транзакции, а третий опционально, а еще хуже, когда, при определенной бизнес логике, нужно выполнить rollback.
Подскажите пожалуйста, как с этим работаете ?
всегда считаете, что, грубо говоря, 1 http запрос есть атомарная операция и безусловно делаете commit (или rollback) ? или сессия проталкивается по всем слоям ?
то Вы ругаете тех, кто хейтит goto, то сами безапелляционно ругаете микросервисы. Нет ничего плохого ни в том, ни в другом. Каждой задаче- свой инструмент, плоха крайность.
а почему нет ? отличная территория, не далеко от города. К слову сказать, в городе такое просто негде строить, Владивосток весь на сопках, весь застроен.
Имхо, продажник, без разработчика никому не нужен. Поиск хорошего разработчика занимает продолжительное время, а вот продажников нет, и их обычно вообще пачками нанимают.
Дерево теоретически можно хранить и в монго, таким образом, но писать дополнительные данные в сам документ с иерархией (напр общее кол-во, время последнего комментария и т.д.), а также обогащать данными другие сущности (напр. сущность пользователя- все его комментарии), но ИМХО- пока все лучше ложится на реляционную структуру.
В монго конечно можно хранить, но не забывать про дополнительные данные, например кол-во комментариев, или вот как с такой структурой получить все комментарии пользователя?
Да, средненький, Вы какой-нибудь битрикс пробовали? а другие популярные cms? так вот, не претендуя на истину- 2 гб это вполне средненький, на 20-40мб катит только чистая статика. Ну и, на вышеупомянутом DO, в отличие от Вашего сервиса, в $20 включена не только память, ну и смею заметить, что DO не самый дешевый.
Было бы совсем не плохо, если бы Вы сделали цены не в $, т.к. не стабильность валюты как-то не способствует планированию и выбору в пользу Вашего сервиса
Понял, спасибо. Тогда что-то не дешево получается, средненький сайтик будет держать, тоже в среднем, 2 gb памяти, т.е. (2gb × 60 × 24 * 30) * ($0,01 ÷ 50gb) = $17,28 в месяц на одну только память
в Воронеже тоже всем пофиг кто ты и что ты
Т.е. в слое сервисов должна порождаться транзакция, и пропихиваться в репозитории ?
Или репозиторий должен содержать транзакционные методы, типа, утрирую, update_post_and_add_comment_and_update_user_and_notify ?
Или же мы должны собирать аггрегат в классическом виде, и его сохранять полностью ?
P.S. не придираюсь ни в коем случае, тема мне очень интересна. За сам пост большое спасибо, +- к этому и пришли.
Боль слоя persistence и БД начинается с транзакциями, когда, например, 2 метода репозитория должны быть выполнены в транзакции, а третий опционально, а еще хуже, когда, при определенной бизнес логике, нужно выполнить rollback.
Подскажите пожалуйста, как с этим работаете ?
всегда считаете, что, грубо говоря, 1 http запрос есть атомарная операция и безусловно делаете commit (или rollback) ? или сессия проталкивается по всем слоям ?
то Вы ругаете тех, кто хейтит goto, то сами безапелляционно ругаете микросервисы. Нет ничего плохого ни в том, ни в другом. Каждой задаче- свой инструмент, плоха крайность.
вот забивать себе слоты для работы- самый лучший совет, хотя и не всегда работает
Справедливости ради- большинство компаний уже давно вывело IT в отдельные ООО
а почему нет ? отличная территория, не далеко от города. К слову сказать, в городе такое просто негде строить, Владивосток весь на сопках, весь застроен.
кампус ДВФУ
Реклама конечно плохо, но ожидаемо. Так-то нужно же содержать и разработчиков, и сервера, денежка наверное кончается
Было бы совсем не плохо, если бы Вы сделали цены не в $, т.к. не стабильность валюты как-то не способствует планированию и выбору в пользу Вашего сервиса