Сохранение прикладных настроек в формате YAML (постановка)
Материал из GedeminWiki
Версия от 12:09, 8 января 2013; SYSDBA (обсуждение | вклад)
- Пространства имен (ПИ) -- это модули, содержащие объекты. Аналог настроек, которые мы сейчас имеем.
- Но, если настройки базируются на алгоритме сохранения в поток реляционных данных, со всеми вытекающими последствиями в виде затягивания сторонних объектов по ссылкам, то ПИ легковесны и не тянут ничего лишнего. В файл попадают только те объекты, которые непосредственно были включены разработчиком в ПИ.
- Для группового включения объектов (например, при добавлении макроса в ПИ должны добавиться и объект макрос и объект скрипт-функция) предусмотрен отдельный внешний механизм.
- ПИ целиком сохраняется в один YAML файл, который состоит из: свойств ПИ, списка ПИ, от которых зависит данное ПИ, списка объектов.
- Имя ПИ является именем YAML файла (без расширения).
- Процесс формирования файла с ПИ называется Сборкой. Процесс считывания файла с ПИ и созданием в БД объектов называется Загрузкой.
- При загрузке в ручном режиме обрабатывается только выбранное ПИ. Проверка на версию и дату изменения не производится.
- При загрузке в пакетном режиме рекурсивно обрабатывается список ПИ, от которых зависит выбранное ПИ.
- Загрузка в пакетном режиме может проходить с принудительной перезаписью всех ПИ (кроме помеченных флагом AlwaysOverwrite = False) или с учетом номера версии и/или даты изменения.
- Если при зугрузке некоторый объект содержит ссылку на объект, который в базе данных отсутствует, то выдается сообщение об ошибке. Процесс загрузки прерывается.
- В файле ПИ мы не храним информацию о типах полей. Вместо этого ПИ содержит ссылки на ПИ со структурами данных (для пользовательских объектов) и номер требуемой версии БД (для системных объектов).
- При установленном свойстве AlwaysOverwrite, в результате загрузки ПИ на базу данных созданные объекты должны в точности соответствовать тому, что находится в дисковом файле. В процессе загрузки дополнительных вопросов о перезаписи не задается.
- Если в процессе загрузки ПИ с диска в базу, в базе уже присутствует прежняя версия ПИ, то объекты которые отсутствуют в дисковом файле (дисковых файлах), но присутствуют в прежней версии, считаются удаленными и удаляются физически из БД.
- Список ПИ хранится в таблице AT_NAMESPACE. Список объектов в -- AT_OBJECT. Объект может входить только в одно пространство имен.
- Поле data таблицы AT_NAMESPACE заполняется при загрузке или сборке ПИ содержимым файла с ПИ.
- Если при сборке ПИ в базе данных отсутствует объект, то в системный лог записывается предупреждение. Сборка не прерывается.
- Режим Разработчика (РР) -- это режим работы программы, доступный под учетной записью Administrator. РР активируется вручную или автоматически при обращении к Редактору скрипт-объектов, Дизайнеру форм или любой форме объектов метаданных или пространств имен.
- В РР объекты, которые были созданы, удалены или изменены фиксируются в таблице AT_OBJECT_LOG. Фиксация происходит на уровне бизнес-объектов.
- Из таблицы AT_OBJECT_LOG соответствующие записи удаляются: а) при сборке ПИ; б) при загрузке ПИ; в) вручную.
Свойства ПИ
| Свойство | Примечание |
|---|---|
| Name | Наименование. При сборке и сохранении на диске используется как имя файла. |
| FileName | Полное имя файла из которого было загружено или в который было сохранено ПИ. |
| FileTimeStamp | Дата файла с ПИ. Заполняется при загрузке ПИ из файла или при сборке ПИ и записи в файл. Может быть пустой для ПИ, которые созданы и еще не разу не собирались. |
| Version | Номер версии. Проставляется вручную. |
| Optional | При загрузке в пакетном режиме пользователю будет дана возможность выбрать загружать/не загружать. |
| Internal | Не будет видна при загрузке в пакетном режиме. |
| DBVersion | Требует версию структуры БД не ниже чем. |
| Comment | Произвольный комментарий. |
Свойства объекта в ПИ
| Свойство | Примечание |
|---|---|
| Class | Имя бизнес-класса. |
| SubType | Подтип. Может отсутствовать, если подтип пустой. |
| AlwaysOverwrite | При загрузке ПИ объект с таким флагом перезаписывает объект, существующий в БД. Если флаг не установлен, то существующий объект будет сохранен в неизменном виде. |
| DontRemove | Если флаг установлен, то при удалении ПИ с объектами из базы, такой объект будет пропущен. |
Пример файла ПИ
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.
- Список связанных объектов. Список содержит название объекта и название ПИ, в которое он входит. Если объект не входит ни в какое ПИ, то данная колонка для него не заполняется. Пользователь галочками может выбрать объекты, которые не входят ни в какое ПИ, для добавления в выбранное ПИ.
- Для сложных объектов список заполнен изначально. Например, если добавляем в ПИ отчет, то в этом списке находятся скрипт-функции Основная, Параметров и Событий, а также шаблон отчета и команда вызова в Исследователе.
- Вверху списка находится кнопка Показать связи и числовое поле ввода Ограничить количество, в котором по умолчанию проставлено число 60. По нажатию на кнопку в список добавляются объекты, от которых в реляционной БД зависит текущий объект.
- Если объект уже входит в ПИ, то с помощью данного окна его можно переместить в другое ПИ или удалить из ПИ. Для последнего предусмотрена кнопка, которая очищает поле выбора ПИ. Т.е. пустое поле ПИ и означает удалить объект из ПИ.
- При перемещении или удалении объекта также перемещаются или удаляются все объекты, отмеченные галочками в списке.
- Форма просмотра списка ПИ. Мастер-дитэйл. Сверху список ПИ, снизу список объектов по выбранному ПИ.
- Диалоговое окно установки очередности объектов в ПИ.
- Форма синхронизации списка ПИ в базе данных с файлами на диске.
- Основное пространство занимает список, состоящий из трех частей. Идея организации списка позаимствована у Total Commander. Слева идет информация о ПИ в базе данных, справа -- о ПИ на диске, а между ними располагается колонка с пиктограммкой выбранного действия. Сверху располагается панель команд и фильтров, а снизу -- область вывода сообщений.
- Список отсортирован по имени ПИ. Кроме имени выводится номер версии и дата изменения.
- Пользователь указывает каталог, где искать файлы с ПИ. Пользователь определяет надо ли сканировать подкаталоги.
- Если в процессе сканирования каталогов найдены одноименные файлы, то только первый файл берется для синхронизации. Предупреждения о всех дубликатах выводятся в панели сообщений.
- Если структура файла не соответствует файлу ПИ, то такой файл пропускается, а информация о нем выводится в панели сообщений.
- Действие для синхронизации определяется следующим образом:
- Если ПИ присутствует слева, но отсутствует справа, то оно помечается для сборки и записи на диск. Если присутствуют подкаталоги, то перед записью файла у пользователя будет запрошено место для размещения файла.
- Если ПИ присутствует справа, но отсутствует слева, то оно помечается для загрузки.
- Если ПИ присутствует с обоих сторон, то направление синхронизации определяется сначала по номерам версий, а при их равенстве по дате изменения файла.
- Пользователь может менять операцию синхронизации.
- Пользователь может открыть окно для сравнения версий ПИ из базы данных и дискового файла.
- Форма установки пакетов.
- Форма сравнения версий ПИ.
- Форма отражения хода выполнения операции по сборке/загрузке ПИ.
Сценарии работы
- Создание ПИ:
- Через форму просмотра.
- Через диалоговое окно добавления объекта в ПИ.
- При загрузке с диска, если такого ПИ нет в базе.
- Добавление объекта в ПИ:
- Вручную с использованием диалогового окна добавления объекта.
- Автоматически для сложных объектов (макрос, отчет, форма и т.п.).
- В полуавтоматическом режиме на основе списка зависимых объектов.
- В полуавтоматическом режиме на основе списка из AT_OBJECT_LOG.
- На основе списка объектов базы данных (метаданные, макросы, отчеты и т.п.), не входящих в ПИ.
- Для объектов с установленным флагом Вложенные в момент сборки ПИ происходит анализ данных и автоматическое добавление в ПИ объектов, которых там еще нет.
- При загрузке ПИ с диска, если в нем присутствую объекты, которых нет в ПИ в базе данных.
- Удаление объектов из ПИ:
- Вручную, с использованием диалогового окна.
- Автоматически, при удалении сложного объекта (макрос, отчет, форма и т.п.).
- При загрузке ПИ, если в загружаемом ПИ такой объект отсутствует.
- В момент сборки, если объект не найден в базе данных.
- В полуавтоматическом режиме на основе списка из AT_OBJECT_LOG.
- На основе списка объектов, входящих в ПИ, но отсутствующих в базе данных.
- Перемещение объекта в другое ПИ:
- Вручную с помощью диалогового окна редактирования объекта ПИ.
- При загрузке с диска, если такой объект уже присутствует в БД, но находится в другом ПИ, он перемещается в загружаемое ПИ.
- Просмотр изменений, сделанных на базе, на основе сравнения сгенерированного текста с файлом.
- Откат изменений через загрузку ПИ из файла.
- Удаление ПИ.
- Удаление ПИ через форму просмотра. Все объекты остаются в базе данных.
- Удаление ПИ через форму просмотра. Объекты из базы данных удаляются, за исключением помеченных флагом DontRemove.
Сделать
NeedModify
Обработка флага NeedModify.
UTF8
На диск файл должен записываться в кодировке UTF-8. При считывании мы должны на лету определять кодировку и при необходимости конвертировать данные в Windows-1251.
FastReport в XML
FR4 позволяет сохранять шаблоны отчетов как в двоичном виде, так и в формате XML. Сейчас, в базе данных мы храним отчеты в двоичном блобе. Разумно было бы сохранять в YAML их ввиде отформатированного XML.
Base64 для бинарных блобов
Возможно, не стоит изобретать велосипед и использовать определенный стандартом тег !!binary для хранения двоичных данных внутри YAML файла. Минус кодировки base64 в том, что мы не увидим изменения отдельного байта при сравнении двух текстовых файлов. Но, так ли нам это надо?
