![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Сижу думаю над шизой.
Имеется описание предметки в виде модели для кодогенерации - хитрозаколдованный набор данных, над которым работают несколько людей и по которому нужно хранить историю.
Для обычной цели "посмотреть кто в прошлом виноват и что делать" истории в виде текстовых diff вполне хватило бы, и набор данных можно представить в любом человеко-машино-читаемом виде (JSON, YAML, итд), засунув его под меркуриал и разбив на несколько файлов по отдельной модели в каждом (там моделей несколько, они зависят друг от друга и работать над ними лучше независимо).
Но вторая цель хранения истории - это генерить патчи для миграции данных, которые эта модель описывает, между версиями модели. Т.е. добавили в модель поле, пару таблиц, еще чего-нибудь навертели - нужно из этого сгенерировать аццкий SQL скрипт, который это все применит к уже работающей базе данных. А тут уже текстовых diff-ов мало.
Можно было бы сделать собственное хранение истории, благо описание самой модели хранится в ней самой и прикрутить к кодогенератору еще и генерацию триггеров аудита изменений особой проблемы нет. Но тогда будет дублирование функциональности меркуриала, причем каждое изменение будет в двух местах - в основных данных, и в логе изменений дописано в конец. Но другого разумного способа сопоставить историю типизированных данных и ее отражение в виде сhangeset-ов меркуриала я не вижу.
Имеется описание предметки в виде модели для кодогенерации - хитрозаколдованный набор данных, над которым работают несколько людей и по которому нужно хранить историю.
Для обычной цели "посмотреть кто в прошлом виноват и что делать" истории в виде текстовых diff вполне хватило бы, и набор данных можно представить в любом человеко-машино-читаемом виде (JSON, YAML, итд), засунув его под меркуриал и разбив на несколько файлов по отдельной модели в каждом (там моделей несколько, они зависят друг от друга и работать над ними лучше независимо).
Но вторая цель хранения истории - это генерить патчи для миграции данных, которые эта модель описывает, между версиями модели. Т.е. добавили в модель поле, пару таблиц, еще чего-нибудь навертели - нужно из этого сгенерировать аццкий SQL скрипт, который это все применит к уже работающей базе данных. А тут уже текстовых diff-ов мало.
Можно было бы сделать собственное хранение истории, благо описание самой модели хранится в ней самой и прикрутить к кодогенератору еще и генерацию триггеров аудита изменений особой проблемы нет. Но тогда будет дублирование функциональности меркуриала, причем каждое изменение будет в двух местах - в основных данных, и в логе изменений дописано в конец. Но другого разумного способа сопоставить историю типизированных данных и ее отражение в виде сhangeset-ов меркуриала я не вижу.
no subject
Date: 2010-06-12 10:58 am (UTC)no subject
Date: 2010-06-12 02:37 pm (UTC)no subject
Date: 2010-06-12 03:08 pm (UTC)no subject
Date: 2010-06-12 03:32 pm (UTC)no subject
Date: 2010-06-12 10:58 am (UTC)В последнее время мне кажется, что схема должна строиться индуктивно от пустой схемы путём применения простых операций: ввести новую сущность, добавить аттрибут сущности, поменять тип, сделать аттрибут обязательным, и так далее. На выходе получим весьма простой способ 1. получения схемы на любой момент времени, 2. отражения этих операций на sql.
Я пока не думал в эту сторону сильно, но следил за своими действиями, когда меняю структуры в немаленькой реляционной базе данных, и вроде пока всё вписывается и всё удобно.
Не продуман вопрос об имеющихся данных: например, для пустой схемы у любой операции есть обратная, тогда как на схеме с данными после удоления аттрибута и внесения его взад данные не появятся.
Далее, про одновременную работу: для каждой пары операций очень просто определить, коммутируют ли они, и можно хорошо уменьшить количество работы / необходимость merge'ить операции от разных людей.
no subject
Date: 2010-06-12 11:00 am (UTC)no subject
Date: 2010-06-12 03:33 pm (UTC)Тогда _удалять_ ничего не потребуется.
no subject
Date: 2010-06-12 05:38 pm (UTC)no subject
Date: 2010-06-12 06:41 pm (UTC)Поставим вопрос иначе. Что мешает писать много маленьких скриптов, а потом из тестовой базы выгружать описание модели?
no subject
Date: 2010-06-12 06:57 pm (UTC)no subject
Date: 2010-06-12 06:59 pm (UTC)no subject
Date: 2010-06-12 07:09 pm (UTC)Просто я хочу это дело заинтегрировать с системой контроля версий, чтобы не повторять ее функциональность.
no subject
Date: 2010-06-12 07:10 pm (UTC)А зачем? Если инструмент не может то, что вам надо, то нужно ли его насиловать?