Реальность такова, что мы хотим, чтобы это было: http://www.liquibase.org/
Liquibase - это библиотека с открытым исходным кодом (Apache 2.0 Licensed), независимая от базы данных, для отслеживания, управления и применения изменений в базе данных. Он основан на простом предположении: все изменения в базе данных хранятся в удобочитаемой, но отслеживаемой форме и проверяются в системе контроля версий.
Однако наш процесс разработки не поддерживает это. Обычно мы не изменяем базу данных с помощью отдельных скриптов, которые мы пишем сами, мы используем подключаемые модули. Мы не пишем сценарии DML для изменения справочных данных, которые мы затем проверяем в управлении исходным кодом, мы используем пользовательский интерфейс на странице администратора и поэтому не имеем исходного кода для последующего использования при репликации этого изменения во время миграции.
Однако мы можем подражать некоторым из них - используя некоторые из инструментов, перечисленных на этой странице:
/programming//q/225772/149060
Например, жидкая база имеет отличительную особенность, которая также, необязательно, включает изменения в данных. Мы могли бы потенциально вывести схему и разность данных в сценарий, исключив (насколько это возможно) определенные таблицы, которые могут включать тестовые данные (например, опубликовать и т. Д.), А затем применить сценарий к производственной базе данных.
MySQLDiff (обсуждаемый в вопросе StackOverflow) выполняет различие схемы, и его автор рекомендует mysql_coldiff для различий в табличных данных - оба они реализованы в perl, если инструменты java (liquidbase) слишком загружены для ваших серверов - хотя обе базы данных локальны и запуск инструмента на вашем ПК решает эту проблему ...
Если мы действительно хотим сделать это правильно, мы должны зарегистрировать любой sql, связанный с настройками, опциями или другими изменениями конфигурации, а также с любыми изменениями схемы - и преобразовать зарегистрированный код в сценарий миграции для игры с нашим рабочим сервером. Воспроизведите сценарий миграции с сервера, скопируйте файлы сайта WordPress (исключая загрузки, если применимо), и мы станем золотыми.
Таким образом, мне кажется, что лучшим выходом является плагин разработчика-разработчика-миграции, который перехватывает SQL-файл, который нам нужен, сохраняет его и затем генерирует сценарий миграции из зарегистрированного кода, а не для создания способа объединения баз данных. между постановкой и производством. Кажется, проще решить проблему.
Если мы посмотрим на код инструментального крюка @bueltge, то плагин вызывает плагин для вдохновения: https://gist.github.com/1000143 (спасибо Рону Реннику через G + за указание мне в направлении SAVEQUERIES и крюку отключения, что ведите меня, чтобы найти его)
- измените его, чтобы получить вывод SAVEQUERIES вместо
- запускать только в режиме администратора
- отфильтровать все выбранные
- сохранить результаты в таблице в хук отключения
- мы могли бы выборочно переключать ловушку на основе того, что мы делали в данный момент.
Например:
Имя захвата: активировать и настроить плагин XYZ
Переключение состояния захвата - на
... установить и настроить плагин XYZ
Переключение состояния захвата - выкл.
Экспорт сценария миграции для: активировать и настроить плагин XYZ
Нажмите кнопку «Экспорт» - чтобы создать всплывающее текстовое поле с отфильтрованным захваченным SQL-кодом - в идеале предварительно отформатированный как сценарий оболочки с вызовом mysql из командной строки. Скопируйте и вставьте его в папку с кодом миграции и добавьте в хранилище исходного кода.
Будьте внимательны, чтобы включать и выключать захват во время работы, и вы сможете сгенерировать идеальный сценарий миграции, чтобы перенести вашу производственную базу данных в эквивалентную конфигурацию с вашей промежуточной базой данных.
Что еще лучше, у вас будет сценарий (или серия таких же), которые вы можете проверить. Imaging с воспроизводимыми, тестируемыми, сценариями миграции !!
Я уже влюблен.
Кто-нибудь еще?