Сохранение прикладных настроек в формате YAML (постановка)

Пространства имен (ПИ) -- это модули, содержащие объекты. Аналог настроек, которые мы сейчас имеем.
Но, если настройки базируются на алгоритме сохранения в поток реляционных данных, со всеми вытекающими последствиями в виде затягивания сторонних объектов по ссылкам, то ПИ легковесны и не тянут ничего лишнего. В файл попадают только те объекты, которые непосредственно были включены разработчиком в ПИ.
Для группового включения объектов (например, при добавлении макроса в ПИ должны добавиться и объект макрос и объект скрипт-функция) предусмотрен отдельный внешний механизм.
ПИ целиком сохраняется в один YAML файл, который состоит из: свойств ПИ, списка ПИ, от которых зависит данное ПИ, списка объектов.
Имя ПИ является именем YAML файла (без расширения).
Процесс формирования файла с ПИ называется Сборкой. Процесс считывания файла с ПИ и созданием в БД объектов называется Загрузкой.
При загрузке в ручном режиме обрабатывается только выбранное ПИ. Проверка на версию и дату изменения не производится.
При загрузке в пакетном режиме рекурсивно обрабатывается список ПИ, от которых зависит выбранное ПИ.
Загрузка в пакетном режиме может проходить с принудительной перезаписью всех ПИ (кроме помеченных флагом AlwaysOverwrite = False) или с учетом номера версии и/или даты изменения.
Если при зугрузке некоторый объект содержит ссылку на объект, который в базе данных отсутствует, то выдается сообщение об ошибке. Процесс загрузки прерывается.
В файле ПИ мы не храним информацию о типах полей. Вместо этого ПИ содержит ссылки на ПИ со структурами данных (для пользовательских объектов) и номер требуемой версии БД (для системных объектов).
При установленном свойстве AlwaysOverwrite, в результате загрузки ПИ на базу данных созданные объекты должны в точности соответствовать тому, что находится в дисковом файле. В процессе загрузки дополнительных вопросов о перезаписи не задается.
Если в процессе загрузки ПИ с диска в базу, в базе уже присутствует прежняя версия ПИ, то объекты которые отсутствуют в дисковом файле (дисковых файлах), но присутствуют в прежней версии, считаются удаленными и удаляются физически из БД.
Список ПИ хранится в таблице AT_NAMESPACE. Список объектов в -- AT_OBJECT. Объект может входить только в одно пространство имен.
Поле data таблицы AT_NAMESPACE заполняется при загрузке или сборке ПИ содержимым файла с ПИ.
Если при сборке ПИ в базе данных отсутствует объект, то в системный лог записывается предупреждение. Сборка не прерывается.
Режим Разработчика (РР) -- это режим работы программы, доступный под учетной записью Administrator. РР активируется вручную или автоматически при обращении к Редактору скрипт-объектов, Дизайнеру форм или любой форме объектов метаданных или пространств имен.
В РР объекты, которые были созданы, удалены или изменены фиксируются в таблице AT_OBJECT_LOG. Фиксация происходит на уровне бизнес-объектов.
Из таблицы AT_OBJECT_LOG соответствующие записи удаляются: а) при сборке ПИ; б) при загрузке ПИ; в) вручную.

Свойства ПИ

Свойство	Примечание
Name	Наименование. При сборке и сохранении на диске используется как имя файла.
Caption	Если задано, то отображается в окне загрузки пакетов. Если не задано, то используется Name.
FileName	Полное имя файла из которого было загружено или в который было сохранено ПИ.
FileTimeStamp	Дата файла с ПИ. Заполняется при загрузке ПИ из файла или при сборке ПИ и записи в файл. Может быть пустой для ПИ, которые созданы и еще не разу не собирались.
Version	Номер версии. Проставляется вручную.
Optional	При загрузке в пакетном режиме пользователю будет дана возможность выбрать загружать/не загружать. По умолчанию False.
Internal	Не будет видна при загрузке в пакетном режиме. По умолчанию True.
DBVersion	Требует версию структуры БД не ниже чем.
Comment	Произвольный комментарий.

Свойства объекта в ПИ

Свойство	Примечание
Class	Имя бизнес-класса.
SubType	Подтип. Может отсутствовать, если подтип пустой.
AlwaysOverwrite	При загрузке ПИ объект с таким флагом перезаписывает объект, существующий в БД. Если флаг не установлен, то существующий объект будет сохранен в неизменном виде. По умолчанию True.
DontRemove	Если флаг установлен, то при удалении ПИ с объектами из базы, такой объект будет пропущен. По умолчанию False.
HeadObject	Для составных частей сложного объекта свойство содержит РУИД главного объекта.

Пример файла ПИ

 StructureVersion: '1.0'
 Name: Test
 Properties:
   Version: 1.1
   Optional: False
   Internal: True
   DBVersion: 0000.0000.0000.0000
   Comment: >
     some comment text
     goes here
 Uses:
   - ПИ 1
   - ПИ 2
   ...
   - ПИ н
 Objects:
   -
     Properties:
       Class: 'TgdcCompany'
       SubType: 
       RUID: 1111111111_2222222
       AlwaysOverwrite: True
       DontRemove: False
     Fields
       Field1: Value1
       Field2: Value2
       ...
   -
     ...

Окна для работы с ПИ

Диалоговое окно добавление объекта в ПИ

Содержит:

Выпадающий список для выбора ПИ.
Флаги AlwaysOverwrite, DontRemove и IncludeSiblings.
Список связанных объектов, который содержит флаг для выбора объекта, название объекта, название ПИ, в которое он входит.
1. Если объект не входит ни в какое ПИ, то последняя колонка для него не заполняется.
2. Для объекта, который уже входит в некоторое ПИ флаг всегда снят и проставить его нельзя.
3. Вверху списка находится кнопка Показать связи и числовое поле ввода Ограничить количество, в котором по умолчанию проставлено число 60.

Добавление в ПИ объекта, который еще не входит ни в какое ПИ:

Поле выпадающего списка пустое или содержит наименование ПИ, сохраненное при последнем обращении к окну.
Флаги AlwaysOverwrite, DontRemove и IncludeSiblings установлены в соответствии со значениями по умолчанию.
Для сложных объектов список связанных объектов заполнен изначально. Например, если добавляем отчет, то в этом списке должны находятся: скрипт-функции Основная, Параметров и Событий, а также шаблон отчета и команда вызова в Исследователе.
1. Объекты, которые не входят ни в какое ПИ изначально помечены галочками для включения в выбранное ПИ.
По нажатию на кнопку Показать связи в список добавляются объекты, от которых в реляционной БД зависит текущий объект.
1. У добавленных таким образом в список объектов галочка изначально не выставляется.
По нажатию на кнопку Ок объекты и объекты, выбранные флагами в списке, добавляются в пространство имен.

Объект входит только в одно ПИ:

Выпадающий список для выбора ПИ заполнен.
Флаги AlwaysOverwrite и DontRemove заполнены значениями из базы данных.
Для сложных объектов список связанных объектов заполнен изначально.
Для перемещения объекта в другое ПИ необходимо выбрать в списке имя ПИ.
1. При перемещении или удалении объекта также перемещаются или удаляются все объекты, отмеченные галочками в списке.

Для последнего предусмотрена кнопка, которая очищает поле выбора ПИ. Т.е. пустое поле ПИ и означает удалить объект из ПИ.

Объект входит в несколько ПИ:

Форма просмотра списка ПИ

Мастер-дитэйл. Сверху список ПИ, снизу список объектов по выбранному ПИ.

Диалоговое окно установки очередности объектов в ПИ

Форма синхронизации списка ПИ в базе данных с файлами на диске

Основное пространство занимает список, состоящий из трех частей. Идея организации списка позаимствована у Total Commander. Слева идет информация о ПИ в базе данных, справа -- о ПИ на диске, а между ними располагается колонка с пиктограммкой выбранного действия. Сверху располагается панель команд и фильтров, а снизу -- область вывода сообщений.
Список отсортирован по имени ПИ. Кроме имени выводится номер версии и дата изменения.
Пользователь указывает каталог, где искать файлы с ПИ. Пользователь определяет надо ли сканировать подкаталоги.
Если в процессе сканирования каталогов найдены одноименные файлы, то только первый файл берется для синхронизации. Предупреждения о всех дубликатах выводятся в панели сообщений.
Если структура файла не соответствует файлу ПИ, то такой файл пропускается, а информация о нем выводится в панели сообщений.
Действие для синхронизации определяется следующим образом:
1. Если ПИ присутствует слева, но отсутствует справа, то оно помечается для сборки и записи на диск. Если присутствуют подкаталоги, то перед записью файла у пользователя будет запрошено место для размещения файла.
2. Если ПИ присутствует справа, но отсутствует слева, то оно помечается для загрузки.
3. Если ПИ присутствует с обоих сторон, то направление синхронизации определяется сначала по номерам версий, а при их равенстве по дате изменения файла.
Пользователь может менять операцию синхронизации.
Пользователь может открыть окно для сравнения версий ПИ из базы данных и дискового файла.

Форма установки пакетов

Форма сравнения версий ПИ

Форма отражения хода выполнения операции по сборке/загрузке ПИ

Форма для работы с дубликатами объектов в разных ПИ

Сценарии работы

Создание ПИ:
1. Через форму просмотра.
2. Через диалоговое окно добавления объекта в ПИ.
3. При загрузке с диска, если такого ПИ нет в базе.
Добавление объекта в ПИ:
1. Вручную с использованием диалогового окна добавления объекта.
2. Автоматически для сложных объектов (макрос, отчет, форма и т.п.).
3. В полуавтоматическом режиме на основе списка зависимых объектов.
4. В полуавтоматическом режиме на основе списка из AT_OBJECT_LOG.
5. На основе списка объектов базы данных (метаданные, макросы, отчеты и т.п.), не входящих в ПИ.
6. Для объектов с установленным флагом Вложенные в момент сборки ПИ происходит анализ данных и автоматическое добавление в ПИ объектов, которых там еще нет.
7. При загрузке ПИ с диска, если в нем присутствую объекты, которых нет в ПИ в базе данных.
Удаление объектов из ПИ:
1. Вручную, с использованием диалогового окна.
2. Автоматически, при удалении сложного объекта (макрос, отчет, форма и т.п.).
3. При загрузке ПИ, если в загружаемом ПИ такой объект отсутствует.
4. В момент сборки, если объект не найден в базе данных.
5. В полуавтоматическом режиме на основе списка из AT_OBJECT_LOG.
6. На основе списка объектов, входящих в ПИ, но отсутствующих в базе данных.
Перемещение объекта в другое ПИ:
1. Вручную с помощью диалогового окна редактирования объекта ПИ.
2. При загрузке с диска, если такой объект уже присутствует в БД, но находится в другом ПИ, он перемещается в загружаемое ПИ.
Просмотр изменений, сделанных на базе, на основе сравнения сгенерированного текста с файлом.
Откат изменений через загрузку ПИ из файла.
Удаление ПИ.
1. Удаление ПИ через форму просмотра. Все объекты остаются в базе данных.
2. Удаление ПИ через форму просмотра. Объекты из базы данных удаляются, за исключением помеченных флагом DontRemove.

Сделать

Конвертация существующих настроек

SELECT
  o.objectclass, o.objectname, o.xid, o.dbid, list(n.name), COUNT(*)
FROM 
  at_object o JOIN at_namespace n ON n.id = o.namespacekey
WHERE
  o.xid > 147000000
GROUP BY
  o.objectclass, o.objectname, o.xid, o.dbid
HAVING
  COUNT(*) > 1
ORDER BY
  COUNT(*) DESC

NeedModify

Обработка флага NeedModify.

UTF8

На диск файл должен записываться в кодировке UTF-8. При считывании мы должны на лету определять кодировку и при необходимости конвертировать данные в Windows-1251.

FastReport в XML

FR4 позволяет сохранять шаблоны отчетов как в двоичном виде, так и в формате XML. Сейчас, в базе данных мы храним отчеты в двоичном блобе. Разумно было бы сохранять в YAML их ввиде отформатированного XML.

Base64 для бинарных блобов

Возможно, не стоит изобретать велосипед и использовать определенный стандартом тег !!binary для хранения двоичных данных внутри YAML файла. Минус кодировки base64 в том, что мы не увидим изменения отдельного байта при сравнении двух текстовых файлов. Но, так ли нам это надо?

Методика тестирования