Как стать автором
Обновить

Комментарии 6

Да. Тема очень актуальная при больших проектах. Но мы написали свое.

Оно может синтаксис парсить на лексические деревья? Чтоб и простые запросы само переводило.
ECM7.Migrator использует другой подход к версионированию, чем ваша утилита. Тут нужно писать классы-миграции, которые будут описывать изменение структуры при переходе между версиями.
Ваша же утилита предназначена для синхронизации двух разных версий структуры БД.

Если говорить в терминах статьи «Версионная миграция структуры базы данных: основные подходы», то вашу diff-утилиту нужно использовать при реализации «Метода уподобления структуры БД исходному коду», а ECM7.Migrator реализует что-то близкое к «Методу инкрементных изменений».
Вами была проделана большая работа и в результате получилось отличное приложение. Если бы мне нужно было привести к заданному виду произвольную БД, вряд ли я нашел бы утилиту лучше Вашей (во всяком случае, среди бесплатных вариантов).

Как правильно заметил Shedal в комментарии выше, Вы используете немного другой подход, чем мы (и эти подходы решают разные проблемы).

Я не совсем понял, зачем нужно парсить синтаксис и куда нужно переводить простые запросы. Скорее всего, данный функционал нужен для решения задач, возникающих при Вашем подходе и не возникающих в случае использования «метода инкрементных изменений».
Кстати, можете ответить на пару вопросов о Вашей утилите?

— можно ли с помощью Вашей утилиты автоматизировать процесс развертывания БД? правильно ли я понял, что для каждой БД нужно сначала руками получить скрипт для преобразования, а потом руками его выполнить?

— как Ваша утилита при переименовании колонки (или таблицы) определяет, что нужно переименовать объект БД, а не удалить старый и создать новый?
Синтаксис нужен (нам), например для перевода VIEW, при миграции логики на другую БД.

Автоматизации нет. Утилита скорее отображение API, который мы готовили для основного проекта. В ней все руками. Вы же понимаете: автоматически удалять и изменять структуру — опасно для здоровья :) Мы сознательно не делали такой возможности.

Переименования нет. Честно вы меня озадачили… Если колонку переименовывают — она же не является тем же объектом, т.е. отследить никак кроме указки пользователя. Если есть такая возможность — подскажите.

Ну и напоследок у меня к вам вопрос: какой практический смысл хранить историю изменений БД?.. Могу предположить, для последовательной обработки данных (помимо структуры), доведения до финального результата?
Как я и писал, наши утилиты используют разные подходы и решают разные проблемы. Я задал эти вопросы, чтобы узнать, насколько утилита, решающая Ваши проблемы, сможет нам помочь в наших проблемах.

На счет истории: храня историю изменений мы, по сути, храним не только информацию о финальной структуре БД, но и о всех промежуточных ее состояниях. Это дает нам возможность легко перевести БД из любого состояния в любое другое состояние (например, любую версию БД обновить до последней версии).

Кроме того, когда разработчик описывает изменения БД, он пишет их не для неизвестной произвольной БД, а для БД заданной версии и он четко знает, в каком состоянии эта БД находится. Например, если мы пишем изменения для перевода БД с версии 4 на версию 5, мы просто пишем коменду «удалить колонку» (без всяких проверок), т.к. можем быть уверены, что в версии 4 эта колонка существует. Таким образом, мы можем очень легко описывать изменения, которые сами по себе получаются очень простыми. Это положительно сказывается на надежности и легкости отладки и поиска ошибок в процессе изменения БД.

Собственно, проблема переименования объектов БД при нашем подходе не возникает в принципе. Если объект нужно переименовать, мы просто пишем команду «переименовать», т.к. мы можем быть точно уверены, что в данной версии существует исходный объект с исходным названием. Т.е. мы явно задаем, какое действие нужно сделать с объектом.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории