Хранилище настроек (постановка)
Flake (обсуждение | вклад) (Новая страница: «Необходимо так организовать хранение данных и метаданных настроек, чтобы было невозможно…») |
SYSDBA (обсуждение | вклад) |
||
| (не показаны 4 промежуточные версии 2 участников) | |||
| Строка 1: | Строка 1: | ||
Необходимо так организовать хранение данных и метаданных настроек, чтобы было невозможно затирание новых изменений функции, например, функцией более старой версии из другой настройки. В статье [[Сохранение настройки в нескольких файлах (постановка)]] предлагается хранить тексты функций, форм и других значимых объектов вне файла настройки. | Необходимо так организовать хранение данных и метаданных настроек, чтобы было невозможно затирание новых изменений функции, например, функцией более старой версии из другой настройки. В статье [[Сохранение настройки в нескольких файлах (постановка)]] предлагается хранить тексты функций, форм и других значимых объектов вне файла настройки. | ||
| − | + | === На все хранилище имеется одна папка с подчиненными настройке файлами === | |
| − | + | В этом случае при сохранении мы всегда указываем корневую папку хранилища. Главный файл настройки сохраняется в корне папки setting (или в папку соответствующую тегу, типу настройки), подчиненные файлы помещаются в папку хранения кода -- data. Папка хранения кода будет содержать файлы vbs, dfm, fr, fr4, sql содержащие логику работы приложения, настройки гридов в XML. | |
| − | + | ||
| − | В этом случае при сохранении мы всегда указываем корневую папку хранилища. Главный файл настройки сохраняется в корне папки setting (или в папку соответствующую тегу, типу настройки), подчиненные файлы помещаются в папку хранения кода - data. Папка хранения кода будет содержать файлы vbs, dfm, fr, fr4, sql | + | |
Получается следующая иерархия папок: | Получается следующая иерархия папок: | ||
| Строка 20: | Строка 18: | ||
::::gdc_frmInvDocument147013038_109092844.dfm | ::::gdc_frmInvDocument147013038_109092844.dfm | ||
:::report\ | :::report\ | ||
| − | ::::Приход_в_ценах_поставщика | + | ::::Приход_в_ценах_поставщика.fr |
| − | ::::Драг_металы. | + | ::::Драг_металы.fr |
:::stored_procedure\ | :::stored_procedure\ | ||
::::USR$AC_GETADDSUM.sql | ::::USR$AC_GETADDSUM.sql | ||
| Строка 28: | Строка 26: | ||
::::USR$INV_INVENTLINE.USR$BI_USR$INV_INVENTLINE.sql | ::::USR$INV_INVENTLINE.USR$BI_USR$INV_INVENTLINE.sql | ||
::::USR$INV_CAR.USR$USR$INV_BI_CAR_NAME.sql | ::::USR$INV_CAR.USR$USR$INV_BI_CAR_NAME.sql | ||
| + | :::grid\ | ||
| + | ::::gdc_frmAttrUserDefinedUSR_AU_PRODUCER(Tgdc_frmAttrUserDefined)_ibgrMain(TgsIBGrid).grid | ||
| + | ::::gdc_frmAttrUserDefinedUSR_AU_PRODUCER(Tgdc_frmAttrUserDefined)_ibgrDetail(TgsIBGrid).grid | ||
::Мат_склад_макросы.xml | ::Мат_склад_макросы.xml | ||
::Общие_данные.xml | ::Общие_данные.xml | ||
| Строка 42: | Строка 43: | ||
</code> | </code> | ||
| − | + | В главной настройке ссылки на подчиненные файлы будут иметь вид: | |
| − | В | + | |
| − | + | ||
<code> | <code> | ||
| − | : | + | :<SCRIPT file="data\function\Acc_CalcNormExpenses.vbs"></SCRIPT> |
| − | + | :<DFM file="data\form\usrf_acc_taxposition.dfm"></DFM> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | </ | + | |
| − | + | ||
| − | < | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
</code> | </code> | ||
| + | |||
| + | |||
| + | Такая структура хранилища настроек полностью опирается на систему контроля версий. Так как в разных настройках могут быть разные версии одной и той же функции, то в процессе сохранения настроек в хранилище файл этой функции будет несколько раз перезаписан. Для избежания этого после сохранения настройки необходимо сделать commit в систему контроля версий. При изменении функции другой настройкой необходимо провести операцию merge для получения функции, которая будет работать и в первой, и во второй настройке. | ||
| + | |||
| + | Также такой подход позволит выявить все проблемы связанные с установкой разных пакетов настроек на одну БД. Все функции, формы, метаданные и гриды будут приведены к общему виду. | ||
| + | |||
| + | [[Category:Постановка-Отклонено]] | ||
| + | __NOTOC__ | ||
Текущая версия на 19:27, 4 января 2013
Необходимо так организовать хранение данных и метаданных настроек, чтобы было невозможно затирание новых изменений функции, например, функцией более старой версии из другой настройки. В статье Сохранение настройки в нескольких файлах (постановка) предлагается хранить тексты функций, форм и других значимых объектов вне файла настройки.
[править] На все хранилище имеется одна папка с подчиненными настройке файлами
В этом случае при сохранении мы всегда указываем корневую папку хранилища. Главный файл настройки сохраняется в корне папки setting (или в папку соответствующую тегу, типу настройки), подчиненные файлы помещаются в папку хранения кода -- data. Папка хранения кода будет содержать файлы vbs, dfm, fr, fr4, sql содержащие логику работы приложения, настройки гридов в XML.
Получается следующая иерархия папок:
- setting\
- data\
- function\
- Acc_CalcNormExpenses.vbs
- Tgdc_dlgGoodBeforePost.vbs
- TgdcInvDocument147006557_63934951_DoOnNewRecord.vbs
- form\
- usrf_acc_taxposition.dfm
- gdc_dlgAttrUserDefinedTreeUSR_ACC_TAXPOSITION.dfm
- gdc_frmInvDocument147013038_109092844.dfm
- report\
- Приход_в_ценах_поставщика.fr
- Драг_металы.fr
- stored_procedure\
- USR$AC_GETADDSUM.sql
- USR$FA_P_YEAR_BETWEEN.sql
- trigger\
- USR$INV_INVENTLINE.USR$BI_USR$INV_INVENTLINE.sql
- USR$INV_CAR.USR$USR$INV_BI_CAR_NAME.sql
- grid\
- gdc_frmAttrUserDefinedUSR_AU_PRODUCER(Tgdc_frmAttrUserDefined)_ibgrMain(TgsIBGrid).grid
- gdc_frmAttrUserDefinedUSR_AU_PRODUCER(Tgdc_frmAttrUserDefined)_ibgrDetail(TgsIBGrid).grid
- function\
- Мат_склад_макросы.xml
- Общие_данные.xml
- data\
При сохранении настройки не в хранилище настроек, или при сохранении настройки-патча, включающего в себя объекты из разных настроек, формируется точно такая же структура:
- VMK_SETTING\
- data\
- function\
- Acc_CalcNormExpenses.vbs
- form\
- usrf_acc_taxposition.dfm
- function\
- 20100928_Исправления.xml
- data\
В главной настройке ссылки на подчиненные файлы будут иметь вид:
- <SCRIPT file="data\function\Acc_CalcNormExpenses.vbs"></SCRIPT>
- <DFM file="data\form\usrf_acc_taxposition.dfm"></DFM>
Такая структура хранилища настроек полностью опирается на систему контроля версий. Так как в разных настройках могут быть разные версии одной и той же функции, то в процессе сохранения настроек в хранилище файл этой функции будет несколько раз перезаписан. Для избежания этого после сохранения настройки необходимо сделать commit в систему контроля версий. При изменении функции другой настройкой необходимо провести операцию merge для получения функции, которая будет работать и в первой, и во второй настройке.
Также такой подход позволит выявить все проблемы связанные с установкой разных пакетов настроек на одну БД. Все функции, формы, метаданные и гриды будут приведены к общему виду.
