Описание и функциональные возможности — различия между версиями

Материал из Course Orchestra
Перейти к: навигация, поиск
Строка 29: Строка 29:
 
* '''Гранула (Grain)''' — функциональная гранула в схеме БД. Для удобства создания и конфигурирования бизнес-приложений, Celesta поддерживает парадигму функциональных гранул, которые можно создавать относительно независимо друг от друга и комбинировать в относительно произвольном порядке. Слово «относительно» здесь означает, что код любой из гранул может свободно использовать объекты и код любой другой гранулы, грамотное проектирование раскладки кода по гранулам — это забота людей, занимающихся программированием бизнес-решений. Аналог гранулы — это пакет в языках Java и Python. Более того, именно по разным пакетам Python для разных гранул раскладываются сгенерированные и созданные вручную файлы кода бизнес-логики на языке Python.
 
* '''Гранула (Grain)''' — функциональная гранула в схеме БД. Для удобства создания и конфигурирования бизнес-приложений, Celesta поддерживает парадигму функциональных гранул, которые можно создавать относительно независимо друг от друга и комбинировать в относительно произвольном порядке. Слово «относительно» здесь означает, что код любой из гранул может свободно использовать объекты и код любой другой гранулы, грамотное проектирование раскладки кода по гранулам — это забота людей, занимающихся программированием бизнес-решений. Аналог гранулы — это пакет в языках Java и Python. Более того, именно по разным пакетам Python для разных гранул раскладываются сгенерированные и созданные вручную файлы кода бизнес-логики на языке Python.
 
* '''Имя гранулы (Grain name)''' — уникальный (для всех решений, когда-либо созданных на Celesta) набор латинских букв и цифр, начинающийся с буквы. Рекомендовано использование только строчных букв. Служит для идентификации гранул и разделения таблиц на пространства имён. Примеры уже сложившихся имён(и гранул): bc, skk, sor, skp. Используется, во-первых, для создания пространства имён таблиц (например, через schema в SQL Server), а во-вторых, для создания пакетов, в которых находятся классы слоя доступа к данным. Таким образом, не существует ограничения на глобальную уникальность имени таблицы среди всех гранул — достаточно уникальности имени таблицы внутри гранулы, т. е. могут одновременно существовать, например, таблицы skk.application и sor.application. Имя гранулы должно быть, по возможности, кратким: во-первых, из-за того, что имя каждой гранулы часто используется в коде, а во-вторых, из-за ограничений реализации в СУБД Oracle, суммарная длина имени гранулы и имени таблицы не может превышать 29 символов.
 
* '''Имя гранулы (Grain name)''' — уникальный (для всех решений, когда-либо созданных на Celesta) набор латинских букв и цифр, начинающийся с буквы. Рекомендовано использование только строчных букв. Служит для идентификации гранул и разделения таблиц на пространства имён. Примеры уже сложившихся имён(и гранул): bc, skk, sor, skp. Используется, во-первых, для создания пространства имён таблиц (например, через schema в SQL Server), а во-вторых, для создания пакетов, в которых находятся классы слоя доступа к данным. Таким образом, не существует ограничения на глобальную уникальность имени таблицы среди всех гранул — достаточно уникальности имени таблицы внутри гранулы, т. е. могут одновременно существовать, например, таблицы skk.application и sor.application. Имя гранулы должно быть, по возможности, кратким: во-первых, из-за того, что имя каждой гранулы часто используется в коде, а во-вторых, из-за ограничений реализации в СУБД Oracle, суммарная длина имени гранулы и имени таблицы не может превышать 29 символов.
* '''Скрипт создания гранулы (Grain creation script)''' — текстовый файл, содержащий скрипт на языке, похожем на SQL DDL в части выражений CREATE TABLE/CREATE INDEX. Предполагается, что возможна разработка и модификация скрипта гранулы с помощью CASE-средств типа DbSchema. Этот файл содержит информацию о  
+
* '''Скрипт создания гранулы (Grain creation script)''' — текстовый файл, содержащий скрипт на языке [[Язык Celesta-SQL|CelestaSQL]]. Возможна разработка и модификация скрипта гранулы [[Проектирование базы данных Celesta в DBSchema|с помощью CASE-средства DbSchema]]. Этот файл содержит информацию о  
 
# таблицах, включая информацию о
 
# таблицах, включая информацию о
 
## полях и их типах (подмножество допустимых типов выбрано таким образом, чтобы обеспечить универсальную поддержку во всех поддерживаемых типах баз данных)  
 
## полях и их типах (подмножество допустимых типов выбрано таким образом, чтобы обеспечить универсальную поддержку во всех поддерживаемых типах баз данных)  
Строка 36: Строка 36:
 
## ограничениях NOT NULL на полях,
 
## ограничениях NOT NULL на полях,
 
# индексах,  
 
# индексах,  
 +
# последовательностях (SEQUENCEs),
 
# связях между таблицами (Foreign Keys),
 
# связях между таблицами (Foreign Keys),
# представлениях (Views).
+
# представлениях (VIEWs).
 
* '''Версия гранулы (Grain version tag)''' — идентификатор версии в виде перечисленных через запятую компонент, явно проставляемый разработчиком гранулы в команде "CREATE GRAIN ... VERSION ..." скрипта гранулы. Служит для защиты от непроизвольного автоматического даунгрейда базы данных при запуске старой версии гранулы на более свежей версии базы данных. Автообновление базы данных никогда не будет выполняться, если version tag в базе данных больше, чем version tag скрипта гранулы, либо если версии несогласованы.
 
* '''Версия гранулы (Grain version tag)''' — идентификатор версии в виде перечисленных через запятую компонент, явно проставляемый разработчиком гранулы в команде "CREATE GRAIN ... VERSION ..." скрипта гранулы. Служит для защиты от непроизвольного автоматического даунгрейда базы данных при запуске старой версии гранулы на более свежей версии базы данных. Автообновление базы данных никогда не будет выполняться, если version tag в базе данных больше, чем version tag скрипта гранулы, либо если версии несогласованы.
 
   [[Файл:danger.png|50px|left|Важная информация]]
 
   [[Файл:danger.png|50px|left|Важная информация]]

Версия 02:14, 20 апреля 2018

Внимание! Вы просматриваете документацию к Celesta 6.x. Документация по Celesta 7.x доступна на courseorchestra.github.io/celesta.

1. Справочник Celesta

1.1 Введение и основные понятия
1.2 Запуск и авто-обновление
1.3 Базовая настройка
1.4 Системные таблицы
1.5 CelestaSQL
1.6 CelestaDoc
1.7 Контексты сессии и вызова
1.8 Курсоры
1.9 BLOB-поля
1.10 Option-поля
1.11 Защита от потерянных обновлений
1.12 Метаданные Celesta
1.13 CelestaUnit

2. Celesta и базы данных

2.1 Особенности работы Celesta с поддерживаемыми типами СУБД
2.2 Проектирование базы данных Celesta в DBSchema

3. Создание решений с использованием Celesta для ShowCase

3.1 Программа обучения Celesta
3.2 Подготовка рабочего места для работы с Celesta
3.2.1 Для разработчиков платформы
3.2.2 Для разработчиков решений
3.3 Системные гранулы Celesta
3.3.1 common
3.3.1.1 Экспорт/импорт данных
3.3.1.2 Навигатор
3.3.1.3 Серии номеров
3.3.1.4 Иерархия Дьюи
3.3.1.5 Системные функции
3.3.1.6 Реестр настроек
3.3.1.7 Mailsender
3.3.1.8 Common.filter
3.3.2 common.api
3.3.4 security
3.3.3 lyra
3.4 Стандартные гранулы Celesta
3.4.1 dirusing
3.4.2 workflow
3.4.3 File repository
3.5 Отрисовка элементов Showcase при помощи Celesta
3.5.1 Конвертер XML-JSON
3.5.2 Навигатор (Navigator)
3.5.3 Информационная панель (Datapanel)
3.5.4 Серверное действие (Server activity)
3.5.5 Вебтекст (WebText)
3.5.6 Грид (Grid)
3.5.6.1 Панель инструментов (ToolBar)
3.5.7 XForms
3.5.7.1 Селекторы
3.5.7.2 Submission
3.5.7.3 Загрузка/Выгрузка файлов (Upload/Download)

5. Решение проблем

5.1 Проблемы с кодировкой jython-файлов

Введение

Функциональные возможности системы

Система Celesta реализует следующее:

  1. Кросс-базданческое проектирование таблиц базы данных решения на платформе,
  2. Поддержка модульности проектирования решений (деления решения на относительно независимые гранулы, комбинируемые относительно произвольным образом),
  3. Обновление базы данных при обновлении версии приложения,
  4. Предоставление промежуточного слоя доступа к таблицам для написания бизнес-логики,
  5. Распределение прав доступа к таблицам,
  6. Логирование входов пользователей в систему и всех изменений, производимых в таблицах.

Система настолько, насколько это возможно прозрачно для разработчиков решения поддерживает следующие типы СУБД (в перспективе данный список может расширяться):

  • MS SQL Server
  • Oracle
  • Postgre SQL
  • H2

Декларация о кодировке UTF-8

Всюду, где это возможно, в системе Celesta подразумевается и требуется, чтобы текстовые данные хранились и передавались в универсальной кодировке UTF-8, причём, в соответствии с рекомендацией консорциума Unicode, без символа BOM. В частности, все CelestaSQL-скрипты и Python-скрипты должны быть сохранены строго в кодировке UTF-8 without BOM.

Основные понятия

Duke2-2.png
  • «Партитура» (Score) — совокупность гранул, с которыми работает данный экземпляр Celesta.
  • Гранула (Grain) — функциональная гранула в схеме БД. Для удобства создания и конфигурирования бизнес-приложений, Celesta поддерживает парадигму функциональных гранул, которые можно создавать относительно независимо друг от друга и комбинировать в относительно произвольном порядке. Слово «относительно» здесь означает, что код любой из гранул может свободно использовать объекты и код любой другой гранулы, грамотное проектирование раскладки кода по гранулам — это забота людей, занимающихся программированием бизнес-решений. Аналог гранулы — это пакет в языках Java и Python. Более того, именно по разным пакетам Python для разных гранул раскладываются сгенерированные и созданные вручную файлы кода бизнес-логики на языке Python.
  • Имя гранулы (Grain name) — уникальный (для всех решений, когда-либо созданных на Celesta) набор латинских букв и цифр, начинающийся с буквы. Рекомендовано использование только строчных букв. Служит для идентификации гранул и разделения таблиц на пространства имён. Примеры уже сложившихся имён(и гранул): bc, skk, sor, skp. Используется, во-первых, для создания пространства имён таблиц (например, через schema в SQL Server), а во-вторых, для создания пакетов, в которых находятся классы слоя доступа к данным. Таким образом, не существует ограничения на глобальную уникальность имени таблицы среди всех гранул — достаточно уникальности имени таблицы внутри гранулы, т. е. могут одновременно существовать, например, таблицы skk.application и sor.application. Имя гранулы должно быть, по возможности, кратким: во-первых, из-за того, что имя каждой гранулы часто используется в коде, а во-вторых, из-за ограничений реализации в СУБД Oracle, суммарная длина имени гранулы и имени таблицы не может превышать 29 символов.
  • Скрипт создания гранулы (Grain creation script) — текстовый файл, содержащий скрипт на языке CelestaSQL. Возможна разработка и модификация скрипта гранулы с помощью CASE-средства DbSchema. Этот файл содержит информацию о
  1. таблицах, включая информацию о
    1. полях и их типах (подмножество допустимых типов выбрано таким образом, чтобы обеспечить универсальную поддержку во всех поддерживаемых типах баз данных)
    2. первичном ключе (primary key) таблицы – его наличие обязательно требуется для работы промежуточного слоя,
    3. DEFAULT-значениях на полях,
    4. ограничениях NOT NULL на полях,
  2. индексах,
  3. последовательностях (SEQUENCEs),
  4. связях между таблицами (Foreign Keys),
  5. представлениях (VIEWs).
  • Версия гранулы (Grain version tag) — идентификатор версии в виде перечисленных через запятую компонент, явно проставляемый разработчиком гранулы в команде "CREATE GRAIN ... VERSION ..." скрипта гранулы. Служит для защиты от непроизвольного автоматического даунгрейда базы данных при запуске старой версии гранулы на более свежей версии базы данных. Автообновление базы данных никогда не будет выполняться, если version tag в базе данных больше, чем version tag скрипта гранулы, либо если версии несогласованы.
Важная информация

Версия состоит из перечисленных через запятую компонент и может выглядеть таким образом: «1.23,TITAN3.34». Читать это нужно следующим образом: базовая версия 1.23, доработка для проекта TITAN – 3.34. Регулярное выражение для проверки формата компонента: ([A-Z_]*)([0-9]+\\.[0-9]+). Требуется, чтобы каждая из составляющих версии имела двухкомпонентный (и только двухкомпонентный!) формат, а префикс либо отсутствовал, либо состоял из заглавных латинских букв и знака подчёркивания. Когда система определяет возможность автоапгрейда, сравниваются все тэги версии последовательно. В этом смысле, по отношению к тэгу «1.23,TITAN3.34»:

  • «1.23,TITAN3.35» – более свежая версия (обновилась модификация), можно выполнять автоапдейт
  • «1.24,TITAN3.34» – более свежая версия (обновилась базовая версия), можно выполнять автоапдейт
  • «1.23,TITAN3.34,PLUTO1.00» – более свежая версия (добавилась ещё одна модификация), можно выполнять автоапдейт
  • «TITAN3.34,1.23» – та же самая версия (порядок следования тэгов не играет роли), автоапдейт выполняться будет лишь при несовпадении контрольных сумм, ошибки не произойдёт
  • «1.22,TITAN3.34» – более старая базовая версия, автоапдейт выполняться не будет, произойдёт ошибка и Celesta остановится.
  • «1.22,TITAN3.36» – несогласующаяся версия, апдейт выполняться не будет, ошибка.

Версии «1.23,PLUTO1.00», «1.25» также будут несогласующимся с версией «1.23,TITAN3.34» и не станут накатываться автоматически (для самоконтроля попробуйте объяснить себе, почему). Каждая из версий сравнивается, как число с плавающей запятой.

  • Контрольная сумма гранулы (Grain checksum) — автоматически вычисляемая контрольная сумма скрипта гранулы (внимание: только лишь скрипта создания! файлы с бизнес-логикой в контрольной сумме не участвуют!) Служит для различения гранул по структуре базы данных. Следует осознавать, что скрипты создания гранул, имеющие одинаковый version tag, могут преднамеренно (в процессе разработки) или непреднамеренно (из-за неаккуратности разработчика) иметь различное содержание. База данных, автоматически сформированная по grain creation script, помимо version tag, хранит и контрольную сумму grain creation script'а, чтобы отследить момент, когда к ней установило контакт приложение с изменённым метаописанием гранулы. Одновременное равенство version tag и grain checksum является достаточным условием для того, чтобы продолжать работу без попыток обновления структуры базы данных. Ради лёгкости проверки и открытости алгоритма контрольная сумма состоит из двух значений: длины файла скрипта (записываемой в формате десятичного числа) и его CRC32 (записываемом в виде 8 шестнадцатеричных цифр).
  • Score path – аналог CLASSPATH для Java, т. е. набор перечисленных через точку с запятой папок с наборами гранул. Папка с набором гранул — это папка, подпапки которой имеют имена гранул, и содержат
    • файл __init__.py инициализации питоновского пакета.
    • скрипты создания гранул _<имягранулы.sql> (подчёркивание в начале нужно для удобной автосортировки файлов) – сгенерированные Python-скрипты с кодом доступа к данным _<имягранулы.py>
    • произвольным образом названные Python-скрипты с бизнес-логикой.
    • субпакеты Python (папки с внутренними модулями __init__.py).

Гранулы из папок с наборами для Celesta «стасовываются» в единый список, т. е. в процессе работы Celesta нет никакой возможности (и необходимости) определить, к какому из наборов принадлежит та или иная гранула. Каждая гранула в системе должна иметь уникальное имя, и если мы работаем всего с одним набором гранул, то уникальность имени обеспечивается файловой системой. Однако используя несколько наборов гранул через точку с запятой, мы не застрахованы от случая, когда гранула с одним и тем же именем через разные наборы входит в систему дважды. В этом случае при инициализации Celesta произойдёт ошибка. Score path задаётся в настроечном .properties-файле, см. раздел Базовая настройка Celesta.

  • Системная гранула celesta — особая гранула, структура таблиц которой не подлежит изменению. Таблицы этой гранулы используются системой во внутренних целях. При этом запись и редактирование данных в части из этих таблиц является частью стандартной настройки системы. Описание гранулы "celesta" см. в разделе «Системные таблицы Celesta».
  • Таблица celesta.grains — системная таблица Celesta в базе данных. Наличие данной таблицы указывает на то, что Celesta подсоединена к «своей» базе данных, в противном случае Celesta будет пытаться развернуть базу «с нуля». Таблица содержит информацию о состоянии гранул, развёрнутых в базе. Описание полей таблицы содержится в разделе «Системные таблицы Celesta». Информация в этой таблице активно используется во время Grain startup sequence (см. далее).
  • Статус гранулы в базе данных (Grain database state) — сохраняемое таблице grains состояние гранулы по отношению к базе, наполненной данными. Может быть одним из следующих:
    • 0 – ready — гранула развёрнута и готова к использованию (при этом её version tag и контрольная сумма записаны в соответствующих полях таблицы grains).
    • 1 – upgrading — гранула находится в процессе создания или апгрейда другим приложением Celesta, подключённым к базе данных.
    • 2 – error — последняя попытка автообновления завершилась неудачно, в этом случае в поле message находится сообщение об ошибке
    • 3 – recover (эквивалент — отсутствие записи в таблице grains при наличии гранулы в папке score) — гранула отсутствует или нуждается в регенерации (например, после ошибки апгрейда)
    • 4 – lock — гранула не нуждается в автоматическом обновлении структуры ни при каких обстоятельствах.
Важная информация

Необходимость статуса upgrading определяется тем, что СУБД Oracle не поддерживает DDL-транзакций. В то же время, мы предполагаем возможность одновременного подключения нескольких серверов приложений Celesta к одной базе данных. Выставление статуса upgrading, поэтому, влияет на grain startup sequence и предотвращает конфликты при автоматическом обновлении.

  • Последовательность запуска гранулы (Grain startup sequence) — операции, выполняемые системой Celesta для каждой гранулы при запуске. При этом, при необходимости, происходит перегенерация классов доступа к данным, а также, при необходимости и возможности, автоапгрейд базы данных (см. далее отдельно про автоапгрейд и activity-диаграммы).
  • Автоапргейд базы данных — составная часть Grain startup sequence, при которой происходит сравнение структуры существующей базы данных со структурой, заданной метаданными в Celesta при помощи скриптов создания гранул. После сравнения разница устраняется с помощью автоматически создаваемых и исполняемых CLREATE/ALTER команд.