Не так, чтобы прям веб программирование, но мне кажется это наиболее подходящий раздел. Компания хочет делать много сайтов с "богатым" контентом: если в терминах таблиц реляционной БД, это скажем 50 таблиц, описывающих некую сравнительно развесистую структуру. Структура конечно заранее неизвестна, компания работает по аджайлу и накручивает схему только по необходимости. Редактировать контент будут минимально обученные джерсийские домохозяйки. Редактировать схему будут программисты. Ну и стоит подчеркнуть, что речь именно про управление контентом, всякие там веб-странички/блоги — это всё не нужно.

Что хочется:

1. Наличие механизма версионирования схем. Чтобы вот у нас v1.0 известная схема, потом v1.1 — тоже известная. Чтобы это всё где-то фиксировалось и можно было историю посмотреть.
2. Наличие механизма миграций контента. Чтобы была возможность в явном виде описать каким образом контент XXX превращается в новой версии в YYY и ZZZ.
3. Наличие механизма версионирования контента. Чтобы было возможность сказать "щас буду делать правки", сделать кучу правок, потом сказать "всё" и получить некий такой идентифицируемый чейнджсет, определяющий разницу между предыдущей версией и текущей.
4. Наличие механизма передачи контента между энвайронтами. В dev поменяли схему, добавили какой-то контент. Посмотрели, вроде нормально. После этого оно как-то переносится в прод. Очень желательно, чтобы это был не убогий "is_draft", что-то вроде "экспортировать content package", "импортировать content package".

Как оно сделано сейчас. Один здоровый XML файл, в котором лежит весь контент (ну и XSD рядом с ним). Версионирование достигается лежанием в гите и применением всех типичных практик программирования: фича бранчи, пул риквесты, теги, и т.д. Миграции делаются "по ситуации". Всегда можно написать какой-то XSLT и из одного XML сделать другой. Передача между энвайронментами достигается в лоб — файл он и есть файл. Минимально обученные джерсийские домохозяйки используют некий хитро настроенный продвинутый XML редактор, который вместо XML показывает формочки. Мне как программисту этот подход (ну, кроме редактора) совершенно нравится. Оно уже год замечательно работает. Джерсийским домохозяйкам не нравится XML редактор и ещё больше не нравится использовать Git. Поэтому я пытаюсь найти какое-то решение, позволяющее "мышкой", но при этом чтоб оставить максимум тех плюсов, которые есть сейчас.

Смотрю например на популярный Strapi: https://strapi.io/

1. Версионирование схем — через гит, ок.
2. Миграции контента — хрен.
3. Версионирование контента — хрен.
3. Передача контента между энвайронментами — хрен.

Как вообще это использовать

Поделитесь опытом если кто решал подобную задачу.

Здравствуйте, rosencrantz, Вы писали:

R>Джерсийским домохозяйкам не нравится XML редактор и ещё больше не нравится использовать Git. Поэтому я пытаюсь найти какое-то решение, позволяющее "мышкой", но при этом чтоб оставить максимум тех плюсов, которые есть сейчас.

Мне тоже не нравится, потому исследую вариант с созданием схемы базы данных в виде классов и коллекций объектов, хранение всего этого в таблице, а редактирование в модели Qt. Вопрос вот в чём, что если нужна динамическая схема данных, где поле может быть, может не быть, а может повторяться несколько раз с одним и тем же именем, но разной циферкой на конце.

названия по ebnf

Поле	Кол-во	Результат	Тип	Не ноль	Первичный ключ	Автоинкремент	Уникальный
id	1	id	INTEGER	✔	✔	✔	✔
group	1	group	TEXT
option	0		TEXT
repeat	2	repeat1, repeat2	TEXT

// запросы схем
const QString Database::SQL_COMMA_DELIMITER = ", ";
const QString Database::SQL_SPACE_DELIMITER = " ";
const QString Database::SQL_CREATE_TABLE = "CREATE TABLE '%1' (%2);";

// ключевые слова
const QString Database::SQL_KEYWORD_NOTNULL =       "NOT NULL";
const QString Database::SQL_KEYWORD_PRIMARYKEY =    "PRIMARY KEY";
const QString Database::SQL_KEYWORD_AUTOINCREMENT = "AUTOINCREMENT";
const QString Database::SQL_KEYWORD_UNIQUE =        "UNIQUE";

// типы sqlite
const QString Database::SQL_TYPE_NULL =            "NULL";
const QString Database::SQL_TYPE_INTEGER =         "INTEGER";
const QString Database::SQL_TYPE_REAL =            "REAL";
const QString Database::SQL_TYPE_TEXT =            "TEXT";
const QString Database::SQL_TYPE_BLOB =            "BLOB";

// таблица table
const QString Database::TABLE_TABLE_NAME =         "table";
const QString Database::TABLE_COLUMN_ID =          "id";
const QString Database::TABLE_COLUMN_GROUP =       "group";
const QString Database::TABLE_COLUMN_OPTION =      "option";
const QString Database::TABLE_COLUMN_REPEAT =      "repeat";

Результат:

CREATE TABLE 'table' (id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT UNIQUE, group TEXT, repeat1 TEXT, repeat2 TEXT);

Развивая эту идею можно добавлять всякие фишки, вроде:
1) table unique key (уникальный ключ в пределах таблицы).
auto generated field — тот самый автоинкремент.
для sqlite создаётся таблица ключей (key table) sqlite_sequence.
2) database unuque key (уникальный ключ в пределах базы данных).
database counter — счётчик базы данных.
держатель значения -1.
в конце редактирования базы данных установка значения.
в случае аварийного завершения -1 исправляется поиском по таблицам наибольшего id.

Можно пойти ещё дальше, в конце концов данные можно сохранить разными способами. Следовательно, если знать схему по которой созданы текущие данные и иметь преобразователь в другую схему, то это можно осуществлять щелчком мыши. Хотя мне не хочется заниматься велосипедописательством, но что-то я не нахожу удобного варианта кроме контроля схемы базы данных из кода согласно своим представлениям о базах данных.

Здравствуйте, velkin, Вы писали:

V>Мне тоже не нравится, потому исследую вариант с созданием схемы базы данных в виде классов и коллекций объектов, хранение всего этого в таблице, а редактирование в модели Qt. Вопрос вот в чём, что если нужна динамическая схема данных, где поле может быть, может не быть, а может повторяться несколько раз с одним и тем же именем, но разной циферкой на конце.

Ох, не. Пилить что-то на коленке мне точно не подойдёт.

Здравствуйте, rosencrantz, Вы писали:

R>Смотрю например на популярный Strapi: https://strapi.io/

Strapi если провести аналогии с вышеописанным это как xml-ка + редактор, 2 в 1

Извлекать данные из него предполагается через API. Домохозяйки редактируют контент через веб-морду, админ закачивает-скачивает, обновляет, проводит миграции через API.

R>1. Версионирование схем — через гит, ок.
R>2. Миграции контента — хрен.
Т.к. мы версионируем контент в гите (см. ниже), то преобразовать его (т.е. файл или файлы), можно скриптом как и ранее.

R>3. Версионирование контента — хрен.
Через АПИ — надо выгружать все изменения куда-то, например в файлы, а их в гит, версиями управлять в гите. Думаю можно даже извратится и преобразовать json в привычный XML, хотя это на любителя.

R>3. Передача контента между энвайронментами — хрен.
Т.к. мы версионируем контент в гите, то как и ранее — передаем файлы нужной версии куда надо.

R>Поделитесь опытом если кто решал подобную задачу.
Я бы эту задачу решал так как описал.. Хотя тут точно нужно программить.