Помимо Saga еще придумали транзакции на CAS. Не то, чтобы шибко сложно, и стороннего сервиса не требует. При аккуратной реализации дает snapshot isolation. См также тынц.
Большое спасибо. Очень интересно почитать про OpenGL. Некоторое время назад занимался его изучением (остановился на таком — камера, текстуры, вывод текста, освещение без теней), но в настоящее время подзабил. Пожалуйста, пишите еще!
Ну тут проблема в том что из-за изменяющихся бизнес требований типа очевидно независимые части внезапно становится зависимыми и наоборот. Пример из практики. Есть аккаунты, они друг с другом никак особо не связаны, можно смело пошардить по ним. Проходит два года и бизнес придумывает реферальную программу из-за которой транзакции на одном аккаунте приводят к изменению на втором аккаунте, и далее по реферальным ссылкам. Внезапно на ровном месте возникли распределенные транзакции между шардами. И это еще не самый сложный пример — логика вычисления комиссии вообще как угодно может меняться, сегодня она одни данные использует, завтра совершенно другие.
Это я к тому что по дэфолту лучше монолит, см выше.
Несколько лет писал микросервисы и в итоге пришел к тем же выводам, что и автор. Как обычно с новыми блестящими технологиями — много хайпа и размахивания руками, мало здравого смысла. В это время суток мне кажется оправданным следующими подход. Если есть монолит, и с ним нет проблем, оставляем монолит. Если с ним есть проблемы, думаем, можно ли решить их НЕ распиливая монолит на сервисы. Если единственное решение в распиливании — распиливаем на сервисы разумного размера (не обязательно микро).
Точно так же есть библиотеки и в мире C, которые можно использовать, а можно не использовать. Все различие в скорости компиляции и типизированности интерфейса.
Про «Вы не платите за то, что не используете» смотрите мой пост.
Хочу также подчеркнуть что мое субъективное мнение — это мое субъективное мнение. Я ни в коем случае никому его не навязываю.
Есть и ряд минусов как у STL, так и в C++ в целом. С моим (субъективным и холиварным спорным по ощущениям многих) мнением по этому вопросу, если действительно интересно, можно ознакомиться здесь. В том же обсуждении в hackers мне несколько человек написало в offlist что разделяют эти опасения.
Если честно, я даже не знаю, как это делается и возможно ли в git. Наверное просто потому что неудобно, проще в commit message указать. Плюс иной раз ревьюверы и тестировщики делают больше, чем сам автор.
Надо спросить коммиттера (Tom Lane), но скорее всего это автоматическое исправление утилитой pgindent. Официально в проекте есть один правильный способ форматировать код — с ее помощью. Но иногда во время разработки код форматируют «на глазок», а потом перед релизом комиттеры прогоняют pgindent по всему коду.
На коммитфесте ищем патчи имеющие состояние Needs Review и с пустым полем reviewer. Можно при желании стать ревьювером к задачи у которой уже есть ревьювер, это не возброняется. Но становится ревьювером к задаче которая waiting for committer довольно бессмысленно.
Ревьювим. Находим соответствующий тред. Пишем туда что-то в таком стиле. Только здесь конкретно я нафакапил, так как поломал тред (надеюсь что сегодня его починю). Просто написать письмо с правильным subject, чтобы оно попало в тред, недостаточно, нужно в письме проставить правильный заголовок In-Reply-To. Или просто следить за тредом с самого начала.
Loriowar, мне кажется, вы попали в одну или даже несколько из этих классических ловушек. Строго говоря комьюнити никому не должно быть разнообразным, и так далее.
Согласен, я бы сам с радостью почитал такие статьи про другие проекты.
Могу написать такую же про FreeBSD, если она будет кому-то интересна. У меня есть пара контрибьюшенов в дерево портов + я временами репорчу минорные баги в ядре.
Я как-то проверял, версией PVS-Studio для Windows еще. Послал пару патчей, один был про бинарный сдвиг на отрицательное число, второй не помню. Можете поискать патчи от меня по git log, их там не много.
Сейчас жду бету для Linux. Если дадут, буду регулярно прогонять ею.
Как мне кажется, это очень мудрое решение. Разработка такого крупного проекта не должна зависеть от новых блестящих SaaS, время от времени меняющих интерфейс на новый, типа улучшенный и более удобный. Алсо GitHub пару раз в год стабильно лежит. С репозиторием PostgreSQL на моей памяти такого ни разу не случалось.
Мне кажется заниматься PostgreSQL, не работая над ним фулл тайм, вряд ли кто-то станет. Это попросту очень затратное по времени занятие. Так что «новая кровь» в лице тех кто не осилил послать git diff по почте не особо поможет. А может и навредит.
Это я к тому что по дэфолту лучше монолит, см выше.
Про «Вы не платите за то, что не используете» смотрите мой пост.
Хочу также подчеркнуть что мое субъективное мнение — это мое субъективное мнение. Я ни в коем случае никому его не навязываю.
холиварнымспорным по ощущениям многих) мнением по этому вопросу, если действительно интересно, можно ознакомиться здесь. В том же обсуждении в hackers мне несколько человек написало в offlist что разделяют эти опасения.Ревьювим. Находим соответствующий тред. Пишем туда что-то в таком стиле. Только здесь конкретно я нафакапил, так как поломал тред (надеюсь что сегодня его починю). Просто написать письмо с правильным subject, чтобы оно попало в тред, недостаточно, нужно в письме проставить правильный заголовок In-Reply-To. Или просто следить за тредом с самого начала.
В первом приближении как-то так.
Могу написать такую же про FreeBSD, если она будет кому-то интересна. У меня есть пара контрибьюшенов в дерево портов + я временами репорчу минорные баги в ядре.
Сейчас жду бету для Linux. Если дадут, буду регулярно прогонять ею.
Сборка PostgreSQL заточенная для 1C, насколько я знаю, никаким стандартам разработки в мире PostgreSQL не противоречит.