Запуск Celesta и авто-обновление БД — различия между версиями

Материал из Course Orchestra
Перейти к: навигация, поиск
 
Строка 15: Строка 15:
 
[[Файл:initialization.png||Сообщения в консоли Eclipse о процессе инициализации]]
 
[[Файл:initialization.png||Сообщения в консоли Eclipse о процессе инициализации]]
 
   
 
   
При '''разборе метаданных''' происходит чтение всех файлов _<имягранулы.py>, их синтаксический анализ и построение внутренней объектной модели базы данных (метаданных). Система в папках score собирает из creation-скриптов информацию о гранулах, таблицах и полях. Вычисляются их контрольные суммы, находятся версии.
+
При '''разборе метаданных''' происходит чтение всех файлов *.sql в алфавитном порядке, их синтаксический анализ и построение внутренней объектной модели базы данных (метаданных). Система в папках score собирает из creation-скриптов информацию о гранулах, таблицах и полях. Вычисляются их контрольные суммы, находятся версии.
  
Процедура '''компиляции''' объектов доступа к данным обновляет все скрипты _<имягранулы.py> на основании скриптов _<имягранулы.sql>. При этом обновление не производится, если контрольная сумма скрипта не изменилась.
+
Процедура '''компиляции''' объектов доступа к данным обновляет все Python-скрипты на основании SQL-скриптов. При этом обновление не производится, если контрольная сумма скрипта не изменилась.
  
 
Процедура '''авто-обновления''' базы данных является наиболее сложной и затратной по времени.
 
Процедура '''авто-обновления''' базы данных является наиболее сложной и затратной по времени.

Текущая версия на 02:18, 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 происходит в два этапа: чтение системных настроек и инициализация Jython. В процессе запуска Celesta в консоль выводится информация о прохождении этих этапов:

Сообщения в консоли Eclipse о процессе пред-инициализации

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

На шаге инициализации Jython происходит инициализация интерпретатора программ на языке Jython, в частности, ему делаются доступными пакеты с классами бизнес-логики.

Инициализация

Инициализация Celesta происходит в три этапа: разбор метаданных, компиляция объектов доступа к данным и авто-обновление базы данных. В процессе запуска Celesta в консоль выводится информация о прохождении этих трёх этапов:

Сообщения в консоли Eclipse о процессе инициализации

При разборе метаданных происходит чтение всех файлов *.sql в алфавитном порядке, их синтаксический анализ и построение внутренней объектной модели базы данных (метаданных). Система в папках score собирает из creation-скриптов информацию о гранулах, таблицах и полях. Вычисляются их контрольные суммы, находятся версии.

Процедура компиляции объектов доступа к данным обновляет все Python-скрипты на основании SQL-скриптов. При этом обновление не производится, если контрольная сумма скрипта не изменилась.

Процедура авто-обновления базы данных является наиболее сложной и затратной по времени.

На этом этапе сервер приложений соединяется с базой данных и проверяет наличие в ней системной таблицы celesta.grains. Если таблица не найдена, она автоматически создаётся (CREATE-командой), однако это происходит лишь в следующих случаях: 1) база данных совершенно пустая 2) в базовой настройке выставлено свойство force.dbinitialize (это защищает от «порчи» существующих, непустых баз данных при ошибочном присоединении к ним системы Celesta). Если в процессе проверки наличия/создания таблицы celesta.grains возникла ошибка, то генерируется фатальная ошибка и система не запускается.

Далее идёт цикл по всем доступным в метаданных гранулам и всем доступным в celesta.grains гранулам.

  1. Если гранула есть в метаданных, но её нет в celesta.grains — выполняется апдейт по creation-скрипту (т. е. предполагается, что таблицы могут и быть).
  2. Если гранула есть в celesta.grains, но её нет в метаданных — ничего не происходит. Автоматически гранулы из базы данных не удаляются, т. к. их таблицы могут содержать важную информацию. Просто в дальнейшем эти таблицы будут недоступны скриптам бизнес-логики Celesta.
  3. Если гранула есть и там, и там: сервер приложений находит в таблице celesta.grains запись про состояние, версию и контрольную сумму метаданных, которые «накатаны» на базу данных при последнем запуске и сравнивает с версией метаданных, которыми сервер располагает.
  • recover (3) — действуем аналогично отсутствию записи.
  • lock (4) — структура не обновляется, переходим к следующей грануле.
  • upgrading (1) — останов процесса с ошибкой “Cannot proceed with database upgrade: there are grains not in 'ready', 'recover' or 'lock' state”.
  • error (2) — останов процесса с ошибкой “Cannot proceed with database upgrade: there are grains not in 'ready', 'recover' or 'lock' state”.
  • ready (0) — продолжение процесса.
  1. Если версия и контрольная сумма совпадают — ничего не происходит.
  2. Если версия различна: если версия изменилась в сторону увеличения — апгрейд вне зависимости от контрольной суммы. Если в сторону уменьшения либо если версия несовместима (см. выше описание логики работы с version tags) — вне зависимости от контрольной суммы останов с ошибкой: “Grain '...' version '...' is lower than / is inconsistent with database grain version '...'. Will not proceed with auto-upgrade.”
  3. Если версия совпадает, а контрольная сумма различна – апгрейд.

Процедура апгрейда гранулы. Если на основании описанного выше алгоритма система решает, что апгрейд гранулы необходим — в грануле сбрасываются все представления и начинается цикл по таблицам в метаданных. Если таблица не найдена в базе, она создаётся. Если таблица найдена — цикл по полям. Если поле не найдено, оно создаётся (следует учесть, что добавление в непустую таблицу not null поля без значения default приводит к ошибке). Если поле найдено, и в нём не совпадает тип, default-значение или ограничение null/not null — конвертируется тип или соответствующие атрибуты поля — опять же, это возможно не всегда, в зависимости от имеющихся в таблице данных. Ошибки на данном этапе приводят к переводу гранулы в состояние error и требуют ручного вмешательства администратора базы данных. После завершения синхронизации таблиц синхронизируются внешние ключи на таблицах, и полностью синхронизируются индексы на таблицах гранулы, чтобы состав индексов в БД соответствовал составу индексов, объявленных в creation-скрипте. В самую последнюю очередь создаются представления (views).

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

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

В Celesta имеется три способа отключить процесс автообновления: