Предисловие переводчика: Уже не помню, что сподвигло меня заинтересоваться этим паттерном, скорее всего это то что в какой-то момент мне пришлось столкнуться с javascript библиотекой redux-saga.
Знакомство началось с описания паттерна от Bernd Rücker и прекрасной презентации Caitie McCaffrey. После ознакомления с этими материалами у меня всё ещё оставались вопросы. Очень хотелось увидеть этот код “в живую” в виде какого либо PoC-a.

Вашему вниманию представлена статья Clemens Vasters-a, которая поможет разобраться уже в деталях с конкретной реализацией.

Сегодня был оживленный день в тех уголках Twitter-а, где обсуждался паттерн Saga. Существует несколько .NET фреймворков, которые используют термин «сага» и которые представляют из себя реализацию конечного автомата или воркфлоу.

Проблема в том, что это всё не сага!

Что такое паттерн сага?

Сага - это шаблон управления сбоями. Saga появилась из осознания того, что долгоживущие транзакции (первоначально даже транзакции внутри базы данных), и особенно далеко распределенные транзакции, пересекающие границы местоположения и / или доверия, не могут быть обработаны с использованием классической модели ACID с двухфазной фиксацией и удерживанием блокировки на время работы (2PC). Вместо этого сага разбивает работу на отдельные транзакции, результаты которых могут быть каким-то образом отменены после того, как работа выполнена и совершена.

Нет такой проблемы которую нельзя было бы усугубить регуляркой (с)

Приходиось ли вам редактировать файлы полные повторяющегося кода? Гигантские файлы с тысячами строк повторяющегося кода. Если приходилось то вы меня поддержите в том что это наверное одна из самых долгих и утомительных задач в разработке. Всё-бы прекрасно решалось если бы у нас были одинаковые строки которые можно решить простой автозаменой, но так как жизнь полна неожиданностей, часто в заменяемых выражениях что-то меняется - то имя переменной другое то метод должен немного отличатся. Как раз для этих целей и был добавлен в автозамену функционал позволяющий выбирать и заменять при помощи регулярных выражений.

Регулярное выражение в этом случае сразу поможет с решением двух проблем:

• поиск с учётом заданной регулярки
• возможность захвата группы символов с последующей вставкой в заменяемый текст

SQLite - это автономная безсерверная SQL база данных.

Д-р Ричард Хипп, создатель SQLite, впервые опубликовал программное обеспечение 17 августа 2000 года. С тех пор он стал вторым по распространённости программным обеспечением в мире. Он используется в важных системах таких как Airbus A350, поэтому неудивительно, что тесты для SQLite 3 сертифицированы для применения в авиации. Само программное обеспечение очень мало, пакет клиента и пакет с библиотекой для системы Debian amd64 составляет 765 КБ в сжатом виде дистрибутива и 2,3 МБ в установленном виде. Программное обеспечение лицензируется по очень лояльной лицензии: Public Domain.

Данный текст явлется переводом. Оригинал по ссылке Предыдущие публикации: Три правила для работы с базой данных Построение базиса Скрипты изменения Работа вьюшками, хранимыми процедурами и пр. Если вы не знакомы с ветвлением и слиянием веток, предлагаю вам отличную HOWTO Control Source Eric Sink’s. Я предпочитаю модель бранчевания “релизная ветка” (примечание переводчика: подходы к ветвлению указанные по ссылкам немного устарели. По-моему мнению стоит уделить внимание более современных подходам git-flow, github-flow и gitlab-flow, но понимание сути возможных проблем при миграции изменений думаю может быть полезно). Читать дальше...

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

После рассмотрения трёх правил и создания базиса, вся команда может работать с базой данных, базис которой безопасно расположен в репозитории контроля версий. Наступит день когда команде предстоит изменить схему. Каждое изменение приводит к новой версии базы данных. В моем подходе, скрипты базиса создали таблицу журнала изменений БД, чтобы отслеживать эти изменения.

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

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

Предостережения

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

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

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

Git распологает широким ассортиментом вариантов делится изменениями без отправления этих изменений на origin. Одним из самых распространённых решений такой проблемы являются патчи. Их легко получить и применить на одном компьютере. Но что делать если на другом компьютере не применяется патч, не переносить же изменения руками?

Представте, что случилась такая ситуация, когда пулл реквест из фиче-бранча оказался немного бажным, но ревьюверы уже приняли его и вмёржили в общий девелоп. Ситуация очень неприятная, особенно если фиче-бранч ВАШ а тесты данную ситауцию почему-то сразу не раскрыли. Фактически, вы заблокировали работу всей команде или того хуже всего проекта с несколькими командами. Как на зло на исправление функционала нужно больше времени чем у вас есть, а злые девелоперы, которые не могут дальше работать уже разжигают костёр обещая Вас на нём поджарить. Что же делаааать?!