Установка прикладного решения

Материал из GedeminWiki
Перейти к: навигация, поиск

Прикладное решение (программа) на платформе Гедымин состоит из:

  • Структур данных (одной или нескольких таблиц, тригеров, хранимых процедур и т.п.)
  • Экранных форм (окон)
  • Программного кода (скрипт-функций, макросов и т.п.)
  • Выходных, печатных форм (отчетов)

На схеме ниже показаны составные части документа Платежное поручение:


ns_01.png


Объекты, составляющие прикладное решение, записываются на диск в один или несколько файлов Пространств Имен (ПИ). Используется формат данных YAML. Файлы пространств имен могут быть просмотрены в любом текстовом редакторе.

Когда решение занимает несколько файлов, для удобства установки разработчик может объединить их в Пакет. Например, Комплексная автоматизация из типовой поставки включает более 240 файлов. При установке мы просто указываем пакет, а система сама определит список нужных пространств имен и порядок их загрузки.

Рассмотрим процесс установки пакета прикладных решений на чистую базу данных.

  • Базу данных берем по этой ссылке.
  • Пространства имен получаем с github и располагаем в папке c:\golden\gedemin-apps

Загружаем Гедымин и подключаемся к базе данных. В главном меню находим пункт Сервис и выбираем команду Синхронизация ПИ...


ns_03.png


В левом верхнем углу вводим (или выбираем) путь к корневой папке с пространствами имен и нажимаем кнопку Сравнить с файлами (F5).


ns_04.png


Список просканированных пространств имен выводится в таблице. В левой части -- ПИ, которые загружены в базу данных (на скриншоте он пуст, так как мы работаем с чистой базой данных). В правой -- ПИ в файлах на диске. Для каждого мы видим номер версии, дату и размер файла. Для установки ПИ выбираем его в списке и по правой кнопке мыши выбираем команду << Пометить для загрузки текущее ПИ и все зависимые. У файлов, которые будут загружены, появится статус <

Далее, на панели инструментов выбираем команду Синхронизировать (F9):


ns_05.png


Запускаем процесс и ждем его завершения. Заходим в окно Синхронизации ПИ и сканируем пространства имен. В правой части списка появятчся только что загруженные позиции:


ns_06.png


Значения статусов в колонке Op

>
Пространство имен присутствует в базе данных, но отсутствует на диске. При выполнении операции Сихронизации ПИ будет записано на диск.
>>
Версия пространства имен в базе данных новее, чем на диске. При выполнении операции Сихронизации ПИ будет записано на диск.
=>
Версии пространства имен в базе данных и на диске совпадают, но хотя бы одно ПИ, от которого зависит данное ПИ, новее в базе данных, чем на диске.
==
Версии пространства имен в базе данных и на диске совпадают.
<
Пространство имен присутствует на диске, но отсутствует в базе данных. При выполнении операции Сихронизации ПИ будет загружено в базу данных.
<<
Версия пространства имен на диске новее, чем в базе данных. При выполнении операции Сихронизации ПИ будет загружено в базу данных.
<=
Версии пространства имен в базе данных и на диске совпадают, но хотя бы одно ПИ, от которого зависит данное ПИ, новее на диске, чем в базе данных.
?
Пространство имен было изменено и на диске и в базе данных (с момента его последней загрузки в базу данных). Необходимо ручное разрешение конфликтов.
!
Не получается найти (ни на диске, ни в базе данных) хотя бы одно ПИ, от которого зависит данное ПИ.

Ответы на частые вопросы

После операции сравнения с каталогом несколько ПИ с списке помечены для загрузки в базу данных или для сохранения на диске. Как выполнить операцию только над одним из них?

По правой кнопке мыши выполняем команду Снять отметку со всех записей. Затем выделяем нужное нам ПИ и по правой кнопке мыши присваиваем ему нужный статус. Далее вызываем команду Синхронизации.

Также заметим, что сохранить одиночное ПИ можно из окна со списком пространств имен.

Как увидеть различия между ПИ в базе данных и файлом на диске?

Выделяем ПИ в списке и по правой кнопке мыши вызываем команду Сравнить (Ctrl-F3).

Почему сразу после загрузки ПИ оно получило статус >>, а не ==?

Это значит, что ПИ отличается от того, что находится в файле. Такая ситуация может возникнуть, если:

  • В файле у объектов есть поля, которых нет в структуре базы данных.
  • В процессе загрузки объектов в базу данных выполняются триггеры или скрипт-функции (перекрытые методы бизнес-объектов), которые меняют данные.

Каким образом определяется, что объект в базе данных был изменен?

При загрузке на базу из файла ПИ запоминается editiondate объекта и сохраняется в поле modified, в таблице AT_OBJECT. Назовем ее исходной датой.

Допустим, через некоторое время ПИ в файле на диске обновилось и мы загружаем его на БД.

Тогда проверяем:

  1. если текущая editiondate у объекта в базе данных равна ИСХОДНОЙ ДАТЕ, то значит объект в базе данных не менялся. Тогда смотрим на дату объекта в файле ПИ. Если она равна ИСХОДНОЙ, то значит что объект вообще не менялся, ни в базе, ни в файле и его трогать не надо. Если дата в файле новее, чем ИСХОДНАЯ, то значит что объект поменялся в файле и его надо загрузить на базу. При этом никаких сообщений дополнительных не будет.
  2. если текущая editiondate новее ИСХОДНОЙ ДАТЫ -- т.е. объект был изменен в базе данных. Тогда смотрим на дату в файле ПИ. Если она равна ИСХОДНОЙ, т.е. объект в файле не менялся, то ничего не грузим и не сообщаем. Если же в файле дата новее ИСХОДНОЙ, значит объект был изменен и тут, и там. Только в этом случае возникнет окно и вопрос к пользователю какие изменения принять, а какие отклонить.
Персональные инструменты
Пространства имён

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