Сохранение прикладных настроек в формате 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.

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

 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
       ...
   -
     ...

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

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

Содержит:

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

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

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

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

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

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

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

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

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

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

Создание ПИ:
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.

Сделать

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

NeedModify

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

UTF8

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

FastReport в XML

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

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

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

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