Обратно-совместимые SQL сценарии

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

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

Чтобы SQL сценарий был обратно-совместимым, при его разработке следуйте рекомендациям, которые приведены в пункте Рекомендации к разработке обратно-совместимых SQL сценариев.

Рекомендации по использованию обратно-совместимых SQL сценариев 

Creatio позволяет выполнить восстановление предыдущего состояния конфигурации из резервной копии пакетов, если установка пакета завершается с ошибкой или по завершению установки наблюдаются проблемы в работе функциональности приложения. Подробнее читайте в статье Процесс управления поставками. Чтобы успешно восстановить предыдущее состояние конфигурации из резервной копии пакетов, конфигурационные элементы типа SQL сценарий (SQL script) должны соответствовать рекомендациям.

Рекомендации, которым должны соответствовать конфигурационные элементы типа SQL сценарий (SQL script) для успешного восстановления предыдущего состояния конфигурации из резервной копии пакетов:

• Отсутствуют новые или измененные конфигурационные элементы типа SQL сценарий (SQL script) пакета. Т. е. дата изменения конфигурационного элемента типа SQL сценарий (SQL script) не отличается от даты его изменения на рабочей среде, на которую планируется установить пакет.
• Новые или измененные конфигурационные элементы типа SQL сценарий (SQL script) пакета являются обратно-совместимыми.

Соблюдение одной из рекомендаций позволяет успешно выполнить восстановление предыдущего состояния конфигурации из резервной копии пакетов.

Реализовать обратно-совместимый SQL сценарий 

1. Создайте конфигурационный элемент типа SQL сценарий (SQL script). Для этого воспользуйтесь инструкцией, которая приведена в статье SQL сценарий.

2. Реализуйте SQL сценарий, который соответствует рекомендациям. Рекомендации описаны в пункте Рекомендации к разработке обратно-совместимых SQL сценариев.

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

   • Анализировать возможное поведение приложения после выполнения текущего SQL сценария.
   • Учитывать влияние текущего SQL сценария на работоспособность приложения после восстановления предыдущего состояния конфигурации.

3. На панели свойств дизайнера сценариев нажмите на кнопку и установите признак Обратная совместимость (Backward compatible). Этот признак указывает, что текущий SQL сценарий является обратно-совместимым. Ответственность за установку признака и соответствие SQL сценария рекомендациям лежит на разработчике, который реализует текущий SQL сценарий.

   

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

Рекомендации к разработке обратно-совместимых SQL сценариев 

Рекомендации по разработке позволяют разработать обратно-совместимые SQL сценарии, которые не приводят к проблемам в работе функциональности приложения после восстановления предыдущего состояния конфигурации. Рекомендации сформированы на основе работы с открытыми источниками, а также с официальной документацией систем управления базами данных MS SQL, PostgreSQL и Oracle, которые поддерживает Creatio.

Принцип ACID — набор свойств, который гарантирует надежную работу транзакций базы данных. О принципе ACID читайте в Википедии.

Свойства, которые являются основой принципа ACID:

• Atomicity — атомарность.
• Consistency — согласованность.
• Isolation — изолированность.
• Durability — надежность.

Один SQL сценарий должен соответствовать одной сущности. Чтобы выполнить несколько SQL сценариев в установленном порядке, воспользуйтесь инструкцией, которая приведена в статье SQL сценарий.

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

Чтобы пересоздать сущность с использованием SQL сценария:

1. Убедитесь в наличии необходимой сущности в таблицах базы данных.
2. Удалите текущую версию сущности.
3. Создайте новую версию сущности. Для этого используйте оператор CREATE, а не ALTER.
4. Свойству Тип установки (Installation type) конфигурационного элемента типа SQL сценарий (SQL script) задайте значение "AfterPackage" или "AfterSchemaData". Подробнее о возможных значениях свойства Тип установки (Installation type) читайте в статье SQL сценарий.

Рассмотрим поведение приложения на примере SQL сценария, который создает работающий с полями триггер. После выполнения SQL сценария при восстановлении предыдущей версии конфигурации из резервной копии пакетов могут наблюдаться проблемы в работе функциональности приложения. Поскольку для восстановленной версии поля, которые создает триггер, — новые, то удалить его невозможно. Соответственно, это может привести к проблемам в работе функциональности приложения.

Под сущностью базы данных необходимо понимать представление, процедуру, функцию, триггер, таблицу базы данных.

Не рекомендуется удалять сущности, если они не используются. Удаление неиспользуемых сущностей приводит к нарушению зависимостей в предыдущих версиях и, соответственно, к проблемам в работе функциональности приложения. После выполнения SQL сценария при восстановлении предыдущей версии конфигурации из резервной копии пакетов удаленные сущности не восстановятся (только если они заново не создаются SQL сценарием в предыдущей версии пакета). Если вы все же решили удалить сущность базы данных, убедитесь, что она не используется в приложении продолжительное время.

Исключением являются ситуации, когда есть необходимость удаления сущностей при удалении приложения с системы (например, при удалении Marketplace-приложений).

Чтобы при удалении приложения удалить сущность с использованием SQL сценария, свойству Тип установки (Installation type) конфигурационного элемента типа SQL сценарий (SQL script) задайте значение "UninstallApp". Подробнее о возможных значениях свойства Тип установки (Installation type) читайте в статье SQL сценарий.

Создание и изменение таблиц базы данных выполняйте с помощью объектов, а не SQL сценариев. Подробнее читайте в статье Объект.

Таблицы базы данных, для создания и изменения которых допускается использование SQL сценариев:

• Временные таблицы.
• Служебные таблицы (т. е. таблицы, которые не содержат бизнес-данные и используются для решения технических задач).

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

• Убедитесь, что изменения, которые описывает SQL сценарий, не приведут к проблемам в работе функциональности приложения.
• Используйте версионность таблиц, которая позволяет выполнять переключение логики между версиями таблицы.
• Убедитесь в наличии полей, таблиц и других объектов, которые используются в SQL сценарии.
• Обратите внимание на использование допустимых таблиц и их полей в индексах, первичных ключах, процедурах, функциях, триггерах и представлениях.

Изменения типа или обязательности полей в таблицах базы данных выполняйте с помощью объектов путем создания нового поля, а не SQL сценариев, которые изменяют существующее поле. Подробнее читайте в статье Объект.

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

Рассмотрим поведение приложения на примере SQL сценария, который изменяет обязательность поля. После выполнения SQL сценария при восстановлении предыдущей версии конфигурации из резервной копии пакетов сохранить запись без заполнения этого поля невозможно, поскольку оно все также будет обязательным.

Добавление обязательных полей со значениями по умолчанию выполняйте с помощью объектов, а не SQL сценариев. Подробнее читайте в статье Объект.

Добавление данных в таблицы базы данных выполняйте с помощью привязок данных, а не SQL сценариев. Подробнее читайте в статье Общие принципы работы с пакетами.

Убедитесь, что данные, которые необходимо добавить с использованием сложного фильтра или особого алгоритма, отсутствуют в таблицах базы данных. В первую очередь, это касается ключевых полей. В процессе отладки приложения SQL сценарий может выполняться несколько раз. Подробнее читайте в блоке статей Отладка. Данные, которые добавляет в приложение SQL сценарий, при восстановлении предыдущей версии конфигурации из резервной копии пакетов не удаляются. Это может привести к проблемам в работе функциональности приложения.

Изменения данных таблиц базы данных выполняйте с помощью привязок данных, а не SQL сценариев. Подробнее читайте в статье Общие принципы работы с пакетами.

Некоторые изменения данных таблиц базы данных, которые выполнены с помощью SQL сценария, невозможно отменить путем выполнения другого SQL сценария или восстановления предыдущей версии конфигурации из резервной копии пакетов. Рассмотрим поведение приложения на примере SQL сценария, который изменяет значение колонки [IsActive] таблицы [SysProcess] базы данных с true на false.

UPDATE SysProcess SET IsActive = true WHERE IsActive = false

После выполнения SQL сценария в колонке [IsActive] таблицы [SysProcess] базы данных отсутствует хотя бы одно значение false. Т. е. неизвестно какие значения колонки изменил SQL сценарий. Разработать SQL сценарий, который отменяет внесенные изменения, возможно, но это требует значительных усилий пользователя.

Не рекомендуется удалять бизнес-данные. Рассмотрим поведение приложения на примере SQL сценария, который удаляет данные поля. После выполнения SQL сценария при восстановлении предыдущей версии конфигурации из резервной копии пакетов данные поля восстановлены не будут. Т. е. будут удалены без возможности восстановления. Не имеет значения, что данные поля добавлял SQL сценарий пакета, до версии которого выполняется восстановление. Создание и изменение данных таблиц базы данных выполняйте с помощью объектов, а не SQL сценариев. Подробнее читайте в статье Объект.

Исключением являются служебные данные (например, очистка очереди планировщика). Но необходимо учитывать, что удаление выполняется без возможности восстановления.

В большинстве случаев отсутствует необходимость вызова процедур и функций в SQL сценариях при установке пакета. При возникновении такой необходимости убедитесь в наличии необходимых процедур и функций в таблицах базы данных.