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

Средний

Функциональность обратно-совместимых SQL сценариев доступна для Creatio версии 8.0.3 и выше.

Если установка пакета завершается с ошибкой, то невозможно полностью восстановить предыдущее состояние конфигурации, поскольку в процессе установки пакета 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 script) без установленного признака Обратная совместимость ( Backward compatible), завершается с ошибкой, то восстановление предыдущего состояния конфигурации из резервной копии пакетов через утилиту WorkspaceConsole будет приостановлено. Подробнее читайте в статье Процесс управления поставками.

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

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

Рекомендация. При разработке SQL сценариев используйте принцип ACID.

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

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

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

Один SQL сценарий должен соответствовать одной сущности. Чтобы выполнить несколько 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 сценарии для удаления сущностей базы данных.

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

Не рекомендуется удалять сущности, если они не используются. Удаление неиспользуемых сущностей приводит к нарушению зависимостей в предыдущих версиях и, соответственно, к проблемам в работе функциональности приложения. После выполнения 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 сценарий, при восстановлении предыдущей версии конфигурации из резервной копии пакетов не удаляются. Это может привести к проблемам в работе функциональности приложения.

Рекомендация. Не используйте 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 сценариев. Подробнее читайте в статье Объект.

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

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

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

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