Особенности работы Celesta с поддерживаемыми типами СУБД

Материал из Course Orchestra
Перейти к: навигация, поиск

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 с поддерживаемыми типами СУБД

Система по возможности прозрачно для разработчиков решения поддерживает MS SQL Server, Oracle, Postgre SQL и H2.

Хотя решения Celesta свободно переносимы между разными типами поддерживаемых СУБД, тем не менее, каждая из этих СУБД имеет особенности настройки. Кроме того, разные функциональные возможности Celesta по-разному реализованы в разных СУБД. Этим особенностям посвящён данный раздел.

Соответствие типов данных Celesta и СУБД приведено в разделе «Язык Celesta-SQL: типы данных».


Mssql.jpg

MS SQL Server

Особенности реализации

  • Понятию «гранула» соответствует понятие «схема» (SCHEMA).
  • Автоинкрементные поля эмулируются при помощи триггеров и таблицы celesta.sequences. Причина в том, что встроенная функциональность IDENTITY в MS SQL Server слишком негибка: установив IDENTITY на столбец таблицы, как-либо поменять это свойство (или этот столбец) без пересоздания всей таблицы с нуля уже невозможно, Celesta же предполагает гибкость изменений структуры.

NB: Начиная с версии 2012, MS SQL Server поддерживает sequences. Планируется доработка Celesta для перехода к использованию функциональности sequences для автоинкрементных полей.


Ora.jpg

Oracle

Особенности настройки

Ошибка ORA-12705: Cannot access NLS data files... Если при запуске Celesta на Oracle Express Edition возникает ошибка "ORA-12705: Cannot access NLS data files or invalid environment specified", в числе аргументов JVM необходимо задать параметр

-Duser.country=US 

Если Celesta запускается из Flute или Showcase, то задать этот параметр можно на вкладке Java, поле Java Options программ Flute2w.exe или Tomcat7w.exe, используемых для управления сервисами Flute/Tomcat.

Эта проблема является общей для связки Oracle XE + JDBC и актуальна только для Oracle Express Edition, в прочих (production) версиях Oracle Database она не актуальна.

Минимальные настройки прав доступа для USER'а в БД Oracle 11g:

GRANT
	CONNECT,
	RESOURCE,
	CREATE TABLE,
	CREATE PROCEDURE,
	CREATE VIEW,
	CREATE SEQUENCE,
	CREATE TRIGGER,
	SELECT ANY DICTIONARY
	TO <USER>

В некоторых организациях по умолчанию не дают право доступа SELECT ANY DICTIONARY, из-за чего может возникать ошибка "ORA-00942: table or view does not exist" при разворачивании системной гранулы Celesta.

Особенности реализации

  • Гранула — префикс в имени таблицы, отделённый знаком подчёркивания, при этом работает ограничение Oracle на длину имени таблицы — 30 символов. Причина в том, что понятие «схема» в Oracle несколько отличается от такового для других СУБД, создание «схем» в Oracle связано с созданием новых пользователей, на что на практике не могут быть выданы права администраторами Oracle-серверов, на которых хранятся промышленные данные.
  • Автоинкрементные поля реализуются при помощи sequences (для каждой таблицы с автоинкрементным полем создаётся SEQUENCE с именем <имя таблицы>_inc) и BEFORE INSERT-триггеров.
  • Oracle не поддерживает конструкцию FOREIGN KEY ... ON UPDATE/DELETE SET NULL, поэтому она эмулируется при помощи триггеров.

Postgre.png

Postgre SQL

Особенности реализации

  • Понятию «гранула» соответствует понятие «схема» (SCHEMA).
  • Автоинкрементные поля реализуются при помощи sequences (для каждой таблицы с автоинкрементным полем создаётся SEQUENCE с именем <имя таблицы>_seq) и специальных DEFAULT-значений на полях, берущих значения из соответствующих sequenc'ов.

При использовании Celesta для доступа к существующей заранее (а не создаваемой и обновляемой в Celesta) базе данных может возникнуть проблема с полями типа uuid. Сама Celesta типа данных uuid как такового не поддерживает, но может работать с ним через поле типа VARCHAR(36). При этом не возникает проблем в MS SQL Server, но для работы Celesta в Postgres требуется явно определить оператор сравнения varchar с uuid и имплицитное изменение типов при присвоении:

CREATE OR REPLACE FUNCTION celesta.uuidequal(a1 uuid, a2 CHARACTER VARYING)
  RETURNS BOOLEAN AS 'select a1::varchar = a2'
  LANGUAGE SQL IMMUTABLE;
 
CREATE OPERATOR = (
    LEFTARG = uuid,
    RIGHTARG = CHARACTER VARYING,
    PROCEDURE = celesta.uuidequal
);

CREATE CAST (character varying AS uuid)
    WITH  INOUT AS ASSIGNMENT;

H2.png

H2

Особенности настройки

  • Для упрощенной инициализации inmemory db в файл celesta.properties можно добавить настройку "h2.in-memory=true". В таком случае строка jdbc подключения будет игнорироваться, а также логин и пароль пользователя.
  • В celesta.properties добавлена поддержка настройки h2.referential.integrity=false(по умолчанию)/true. Выключенная настройка означает, что ограничения типа constraint будут проигнорированы при записи в БД. При включении ограничения будут обрабатываться как в других РСУБД. Для установки данной настройки не в inmemory БД пользователь должен обладать правами администратора(поле "ADMIN" в таблице "INFORMATION_SCHEMA.USERS") Данная настройка срабатывает один раз при инициализации приложения и для обновления требуется его перезапуск.

Особенности реализации

  • Понятию «гранула» соответствует понятие «схема» (SCHEMA).
  • Автоинкрементные поля реализуются при помощи sequences (для каждой таблицы с автоинкрементным полем создаётся SEQUENCE с именем <имя таблицы>_seq) и специальных DEFAULT-значений на полях, берущих значения из соответствующих sequenc'ов.
  • Поля 'recversion' управляются триггером, написанном на Java и реализующим интерфейс org.h2.api.Trigger. H2 не поддерживает триггеры, логика которых заключена в процедурном SQL.