Строго типизированные данные, история их версий и меркуриал

[metaclass]

Сижу думаю над шизой.
Имеется описание предметки в виде модели для кодогенерации - хитрозаколдованный набор данных, над которым работают несколько людей и по которому нужно хранить историю.
Для обычной цели "посмотреть кто в прошлом виноват и что делать" истории в виде текстовых diff вполне хватило бы, и набор данных можно представить в любом человеко-машино-читаемом виде (JSON, YAML, итд), засунув его под меркуриал и разбив на несколько файлов по отдельной модели в каждом (там моделей несколько, они зависят друг от друга и работать над ними лучше независимо).
Но вторая цель хранения истории - это генерить патчи для миграции данных, которые эта модель описывает, между версиями модели. Т.е. добавили в модель поле, пару таблиц, еще чего-нибудь навертели - нужно из этого сгенерировать аццкий SQL скрипт, который это все применит к уже работающей базе данных. А тут уже текстовых diff-ов мало.

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

Comments

[zamotivator.livejournal.com]

А что мешает написать скрипт, который использую утилиты mercrial сам пройдётся по системие контроля версий, посмотрит на diff'ы, и сгенерит всё что недо?

[dmitry-vk.livejournal.com]

Поддерживаю этот вариант. И, конечно, diff должен быть не текстовым построчным, а должен сравнивать структуры.

[metaclass.livejournal.com]

А, в принципе логично. Конвертировать ревизии в данные и сравнить.

[zamotivator.livejournal.com]

О чём и речь

[gds.livejournal.com]

не про меркуриал и совсем не про diff-ориентированный подход. Наоборот, про patch-ориентированный.
В последнее время мне кажется, что схема должна строиться индуктивно от пустой схемы путём применения простых операций: ввести новую сущность, добавить аттрибут сущности, поменять тип, сделать аттрибут обязательным, и так далее. На выходе получим весьма простой способ 1. получения схемы на любой момент времени, 2. отражения этих операций на sql.
Я пока не думал в эту сторону сильно, но следил за своими действиями, когда меняю структуры в немаленькой реляционной базе данных, и вроде пока всё вписывается и всё удобно.
Не продуман вопрос об имеющихся данных: например, для пустой схемы у любой операции есть обратная, тогда как на схеме с данными после удоления аттрибута и внесения его взад данные не появятся.
Далее, про одновременную работу: для каждой пары операций очень просто определить, коммутируют ли они, и можно хорошо уменьшить количество работы / необходимость merge'ить операции от разных людей.

[gds.livejournal.com]

если рассматривать diff-ориентированный подход, то, очевидно, требуется всё "денормализовать" так, чтобы пара строк (удалённая и добавленная) несла полную информацию о том, что поменялось. Если одна сущность раскинется более чем на одну строку, дифф рано или поздно превратится в тыкву.

[zamotivator.livejournal.com]

Кстати, да. Как вариант - в систему контроля версий складывать patch'и, а потом некоторой тулзой точками времени x1 и x2 получать скрипт на миграцию.

Тогда _удалять_ ничего не потребуется.

[metaclass.livejournal.com]

Это совпадает с моим вторым вариантом, когда хранилище для данных само по себе ведет историю изменений, т.е. дублирует функциональность контроля версий. В принципе, особой проблемы в этом наверно и нет.

[permea-kra.livejournal.com]

>> Т.е. добавили в модель поле, пару таблиц, еще чего-нибудь навертели - нужно из этого сгенерировать аццкий SQL скрипт, который это все применит к уже работающей базе данных.

Поставим вопрос иначе. Что мешает писать много маленьких скриптов, а потом из тестовой базы выгружать описание модели?

[metaclass.livejournal.com]

Модель первична, скрипты миграции - следствие.

[permea-kra.livejournal.com]

Что мешает описать модификации модели как набор последовательных операций, в скрипты миграции транслируемые однозначно ?

[metaclass.livejournal.com]

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

[permea-kra.livejournal.com]

>>Просто я хочу это дело заинтегрировать с системой контроля версий,чтобы не повторять ее функциональность.
А зачем? Если инструмент не может то, что вам надо, то нужно ли его насиловать?