Управління структурами таблиць моделі даних реєстру
Опис проблеми
Частиною процесу створення/редагування регламенту реєстру є опис моделі даних реєстру. Поточний підхід передбачає використання лише файлів конфігурації для створення моделі даних реєстру. Користувач повинен використовувати liquibase changelog формат опису моделі даних, що де-факто є описом структури БД.
Частиною web-based адмін порталу редагування версії регламенту реєстру є редагування структури БД. Необхідно розробити технічний дизайн підсистеми створення моделі даних реєстру.
Ключові пункти проблеми
-
Одночасна робота декількох користувачів з однією версією-кандидатом регламенту
-
Збереження механізму забезпечення існуючого життєвого циклу регламенту версій (gerrit, jenkins)
-
Збереження технічного інструменту відтворення структури БД (liquibase)
-
Збереження механізму зміни регламенту шляхом зміни конфігураційних файлів в git
-
Забезпечення синхронізації між змінами з адмін порталу і змінами внесеними через Gerrit
-
Створення GUI based механізму зміни регламенту реєстру
Базові сценарії використання
-
Створення нової версії регламенту реєстру
-
Виконання дозволені CRUD like операцій з моделлю данних, що описані нижче
-
Перегляд всієї історії змін моделі даних регламенту реєстру
-
Перегляд історії змін моделі даних регламенту реєстру всередині версії-кандидату
-
Збереження змін в моделі даних до версії-кандидату
-
Інспекція версії-кандидату регламенту реєстру
Out of scope
-
Робота з типами даних
-
Робота з аналітичними представленнями
-
Вирішення конфліктів з використанням адмінпорталу менеджменту регламенту реєстру
Принципи роботи зі змінами в БД
Існуючий механізм роботи зі змінами в БД
Існуючий механізм роботи зі змінами в БД базуєтсья на двух принципах:
-
Cтворення liquibase changeset
-
Збереження liquibase changeset в git
Розширений механізм роботи зі змінами в БД
Пропонується розширити існуючий механізм роботи зі змінами БД шляхом додавання DataModelSnapshot документу в git репозиторій, котрий буде відображати стан моделі даних.
Основні концепції
-
DataModelSnapshot model - JSON документи, що відображають стан моделі даних регламенту реєстру
-
Diff Document - документ, що відображає різницю між двома станами моделі даних регламенту реєстру
-
History Document - документ, що відображає історію змін мастер версії або версії- кандидату регламенту реєстру
Описання структури DataModelSnapshot
| Вищенаведена модель даних була отримана в результаті аналізу існуючого стану lqiuibase changelogs (включно з аналізом функціональності custom liquibase тегів) |
Опис структури файлів на файловій системі
DataModelSnapshot model має наступну структуру файлів на файловій системі
-
Перелік таблиць визначається переліком файлів на файловій системі
-
Ім’я файлу таблиць відповідає назві таблиці та має наступний вигляд:
<table-name>.json -
Ім’я файлу role permission відповідає назві id role permission та має наступний вигляд:
<role-id>.json
Опис DataModelSnapshot формату даних
В якості технічного інструменту опису структури даних DataModelSnapshot використовується Json формат. В якості опису контракту документу використовується JsonSchema
Допустимі операції з об’єктами доменної моделі
| Нижче наведена інформація базується на існуючому контракті по роботі з моделлю даних регламенту реєстру. В контексті даної проблеми цей контракт є джерелом функціональних можливостей, що мають бути взяті до уваги при розробці технічного дизайну. |
Допустимі операції відносно моделі даних регламенту реєстру діляться на 2 групи:
-
Обмежена можливість змін моделі даних
-
Повна можливість змін моделі даних
| Об’єкти моделі даних, що не були інтегровані в мастер-версію регламенту реєстру, можуть бути змінені будь-яким чином не зважаючи на нижче вказані обмеження. |
Об’єкти моделі даних, що ввійшли до master версії snapshot data model мають обмежені можливості для редагування. Таблиці, що були створені в CandidateSnapshot не мають ніяких обмежень відносно можливостей редагування.
Описання атрибутів доменної моделі
Table
| Назва | Тип | Read only | Описання |
|---|---|---|---|
Name |
string |
true |
|
HistoricalFlag |
boolean |
true |
|
ObjectReference |
true |
||
Description |
String |
false |
Column
Назва |
Тип |
Read only |
Описання |
Name |
string |
true |
|
Description |
string |
false |
|
Type |
enum[clarify types] |
true |
|
DefaultValue |
object |
false |
|
NotNull |
boolean |
true |
|
Unique |
boolean |
true |
|
PrimaryKey |
boolean |
true |
Index
Назва |
Тип |
Read only |
Описання |
Name |
string |
true |
|
Columns |
[{ name string sorting: enum[ASC, DESC, NONE] }] |
false |
Загальні принципи реалізації
-
Механізм дозволяє проводити CRUD операції відносно об’єктів доменної моделі
-
Одночасне редагування регламенту реєстру як з використанням адмін порталу, так і шляхом зміни конфігураційних файлів в репозиторії регламенту
-
Стан структури БД і метаданих повністю відображений DataModelSnapshot документами
-
Структура DataModelSnapshot json документів описана за допомогою JSONSchema
-
DataModelSnapshot документи (з JSONSchema) мають бути використані як структура обміну даними на рівні RestAPI між Front-End додатком та Backend сервісами
-
Вирішення конфліктів при редагуванні регламенту реєстру з використанням адмінпорталу необхідний лише на рівні DataModelSnapshot документів
-
Підтримання консистентними DataModelSnapshot моделі та liquibase changelog
-
Процес синхронізації DataModelSnapshot моделі по liquibase changelog є ідемпотентним
-
Зміни внесені через адміністративний портал знаходяться в окремому liquibase changeset. Ідентифікатор версії-кандидату є частиною liquibase changeset id атрибуту.
