Сохранение настройки в нескольких файлах (постановка)

Материал из GedeminWiki
(Различия между версиями)
Перейти к: навигация, поиск
(Сохранять тег ROW в отдельном файле)
Строка 1: Строка 1:
Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка ([[Пакет настроек|пакет]]), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий.
+
Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка ([[Пакет настроек|пакет]]), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий. Можно рассматривать два подхода решения данной проблемы.  
  
Рассмотрим варианты решений.
+
* В первом случае, мы не изменяем существующий механизм сохранения настройки в XML. Вместо этого мы разбиваем существующую настройку на более мелкие и сохраняем их поотдельности.
 +
* Во втором -- изменяем механизм сохранения и выносим составные части XML в отдельные файлы.
 +
 
 +
Рассмотрим второй вариант подробнее.
  
 
=== Сохранять тег ROW в отдельном файле  ===
 
=== Сохранять тег ROW в отдельном файле  ===
Строка 31: Строка 34:
 
== Оптимизация XML файла настроки ==
 
== Оптимизация XML файла настроки ==
  
Так же следует уделить внимание оптимизации хранения данных. Например, указывать флаги MODIFYFROMSTREAM и т.п. на уровне таблицы, а для каждой строки указывать их только в том случае, если они отличаются.
+
Так же следует уделить внимание оптимизации хранения данных. Например, зафиксировать дефолтные значения флагов MODIFYFROMSTREAM и др. в спецификациях. Тогда для каждой строки указывать их только в том случае, если они отличаются.
  
 
[[Category:Постановка]]
 
[[Category:Постановка]]

Версия 10:46, 27 сентября 2010

Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка (пакет), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий. Можно рассматривать два подхода решения данной проблемы.

  • В первом случае, мы не изменяем существующий механизм сохранения настройки в XML. Вместо этого мы разбиваем существующую настройку на более мелкие и сохраняем их поотдельности.
  • Во втором -- изменяем механизм сохранения и выносим составные части XML в отдельные файлы.

Рассмотрим второй вариант подробнее.

Содержание

Сохранять тег ROW в отдельном файле

Введем максимальный размер тега ROW. При формировании XML будем проверять на этот размер. Если тег получился большего размера, то выносим его содержимое в отдельный файл с именем:

 ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML

Для подключения файла в общий XML мы можем либо воспользоваться механизмом включения файлов, либо реализовать отдельную загрузку при обработке XML настройки. В последнем случае в тексте настройки прописываем имя файла в атрибуте fname тега ROW:

 <ROW fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML" />

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

Сохранять группу тегов ROW в отдельном файле

Аналогично предыдущему, но в файл выгружается не один, а несколько тегов ROW.

Сохранять исходные тексты скрипт-функций в отдельных файлах

Определяем таблицы и поля, которые хранят исходный код скрипт-функций, DFM экранных форм, отчеты. Каждое такое поле сохраняем в отдельном текстовом файле безо всякой дополнительной разметки. Имя файла:

 ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.ПОЛЕ.РАСШИРЕНИЕ

Расширение файла указывается в соответствии с типом записанного в него кода. Например: VBS, DFM, XML и т.п. В теги полей сохраненных в отдельных файлах добавляем атрибут fname.

Минусы, как и в первом варианте, это большое количество файлов и невозможность использовать стандартные средства поиска по XML и трансформинга. Плюсы в том, что тексты программ хранятся именно как тексты программ, без дополнительной разметки.

Оптимизация XML файла настроки

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

Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Инструменты