Блог

Я работаю с Progress 11.6 AppBuilder и редактором процедур (и словарем данных).

Регулярно мы вносим изменения в базу данных клиента, есть два типа изменений:

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

Пример изменения данных в процедуре обычно выглядит следующим образом:

 FOR EACH Table1 WHERE Table1.Field1 = <value>:
  CREATE Table2. 
  Table2.Field1 = <value>.
  Table2.Field2 = <some-other-value>.
END.
 

Это полностью противоречит одной из основ количественной доставки программного обеспечения — повторяемости: нет никакого способа вернуться к предыдущей ситуации!

Поэтому я ищу способы сделать это (автоматизируемым) повторяемым способом, отсюда и мои вопросы:

• Что мы можем использовать вместо интерактивного графического интерфейса словаря данных (без функции отмены) для выполнения / отмены изменений структуры базы данных?
• Что мы можем сделать, чтобы отменить изменения данных базы данных? (Выполняется ли что-то вроде a Oracle redo log или a Oracle archive log ?)

В случае, если вы скажете «О чем вы говорите? Вы можете выполнить «Отменить транзакцию» в словаре данных.«, я имею в виду следующее:
Я выполняю транзакцию, используя словарь данных, я оставляю словарь данных, а на следующий день клиент жалуется. Когда я открываю словарь данных в этот момент, функция «Отменить транзакцию» отключена.

На высоком уровне вы должны создавать «файлы df» (скрипты DDL) и применять их к базе данных клиентов, а не вносить изменения вручную. Существует много способов создания этих файлов, и вы можете автоматизировать весь процесс с помощью соответствующего инструментария.

Один из наиболее распространенных способов создания файла df — создать любую новую схему, которая вам нужна, в вашей базе данных разработки, а затем использовать средство «создать инкрементный df» в инструменте «Словарь данных». Этот инструмент сравнивает схему базы данных разработки с целевой схемой и создает «df-файл» (DDL-скрипт) различий. Вы можете подключиться непосредственно к целевой базе данных для этого процесса или у вас может быть пустая базовая база данных, которую вы используете для этого.

Как создать инкрементный df-файл

(Если вы затем отмените сравнение, вы также можете создать обратный df-файл, чтобы отменить изменения.)

Большинство файлов df состоят из дополнений — новых таблиц, новых полей, новых индексов. Все это может быть добавлено онлайн, и все это может быть полностью написано по сценарию. И, конечно же, отдельные файлы df и все вспомогательные скрипты могут (и должны) храниться в репозитории (например, git или любом другом).

Что касается сценариев изменения данных … нет никаких причин, по которым эти программы не могут быть написаны как настоящие программы и сохранены в репозитории. Вы можете вложить все обновление в транзакцию и ОТМЕНИТЬ его, если это необходимо. Как бы то ни было, лично я не думаю, что это очень хорошая идея. Особенно, когда речь идет о больших объемах данных, вы действительно не хотите создавать чудовищные многогигабайтные журналы отмены. Вам лучше использовать второй сценарий «обратной транзакции», который будет откатывать все по частям. Побочным преимуществом является то, что вы все еще можете использовать это, если решите отказаться от внесения изменений через день или три после этого.

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