Миграция
Информационная система, разработанная на базе платформы lsFusion, использует в качестве постоянного хранилища данных реляционную систему управления базами данных. При этом необходимо учитывать, что после определенных изменений логики системы платформа не может определить, каким образом нужно мигрировать данные. В таких случаях разработчик обязан явно указывать способ миграции путем создания специального миграционного файла migration.script
, который должен находиться в CLASSPATH сервера приложения.
Миграционный файл состоит из блоков, которые описывают изменения, произведенные в указанной версии структуры базы данных. При старте сервера применяются все изменения из миграционного файла, которые имеют версию выше, чем версия, хранящаяся в базе данных. Изменения применяются в соответствии с версией, от меньшей версии к большей. Если изменение структуры БД происходит успешно, то максимальная версия из всех примененных блоков записывается в базу данных в качестве текущей. Синтаксис описания каждого блока выглядит следующим образом:
V<номер версии> {
изменение1
...
изменениеN
}
Номер версии пред ставляет собой набор из одного или нескольких чисел разделенных точкой. При сравнении номеров двух версий сравниваются сначала первые числа версий, при их равенстве вторые и т. д. Если в одном номере версии меньше чисел, чем в другом, то при сравнении версия с меньшим количеством чисел дополняется нолями. То есть номер версии 1.3
эквивалентен номеру 1.3.0.0
, а версия 1.2
больше версии 1.1.3
. В миграционном файле номер версии указывается вместе с заглавной буквой V
: V1.0
, V2.0.11
.
Миграционный файл позволяет обрабатывать изменения канонических имен элементов системы, которые происходят при переименовании и/или переносе в другое пространство имен. Изменения бывают следующих типов:
PROPERTY oldNS.oldName[class1,...,classN] -> newNS.newName[class1,...,classN]
STORED PROPERTY oldNS.oldName[class1,...,classN] -> newNS.newName[class1,...,classN]
FORM PROPERTY oldNS.oldFormName.oldName(object1,...,objectN) -> newNS.newFormName.newName(object1,...,objectN)
CLASS oldNS.oldName -> newNS.newName
OBJECT oldNS.oldClassName.oldName -> newNS.newClassName.newName
TABLE oldNS.oldName -> newNS.newName
NAVIGATOR oldNS.oldName -> newNS.newName
Изменение имени свойства или действия
При переименовании свойства (действия) и/или при переносе его в другое пространство имен происходит изменение канонического имени этого свойства (действия). Добавление изменения типа PROPERTY
в файл миграции с указанием старого и нового канонических имен позволит сохранить настройки политики безопасности, а также настройки из таблицы Reflection.properties
. Если же свойство является первичным, то для сохранения данных при изменении канонического имени такого свойства необходимо добавить изменение типа STORED PROPERTY
. Тогда при запуске сервера соответствующее этому свойству поле в таблице БД будет переименовано. В противном случае старое поле будет переименовано в поле с именем <старый идентификатор>_deleted
, как в случае удаления свойства, а новое поле будет создано с пустыми значениями. В остальном тип STORED PROPERTY
эквивалентен типу PROPERTY
.
В правой части изменений типа STORED PROPERTY
и PROPERTY
необязательно указывать сигнатуру, в этом случае сигнатура автоматически возьмется из левой части.
Изменение имени свойства (действия) на форме
При изменении имени свойства на форме с помощью миграционного файла можно сохранить информацию из настройки таблиц для этого свойства (действия) на форме, для этого иcпользуется тип изменения FORM PROPERTY
. В качестве старого и нового имен выступают имя пространства имен формы, имя формы и имя свойства на форме, перечисленные через точку. Также с помощью этого типа изменения можно сохранить информацию из настройки таблиц при изменении канонического имени формы. Для этого необходимо добавить в миграционный файл изменения типа FORM PROPERTY
для всех свойств (действий) на форме с измененным каноническим именем формы.