Реальність така, що ми хочемо, це таке: http://www.liquibase.org/
Liquibase - це відкритий код (ліцензований Apache 2.0), незалежна від бази даних бібліотека для відстеження, управління та застосування змін до бази даних. Він побудований на простому приміщенні: всі зміни бази даних зберігаються в читаному, але відслідковуваному вигляді, і перевіряються у контролі джерел.
Однак наш процес розробки цього не підтримує. Зазвичай ми не змінюємо базу даних за допомогою дискретних сценаріїв, які ми пишемо самі, ми використовуємо плагіни, які ми активуємо. Ми не пишемо сценарії 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
Capture State Toggle - увімкнено
... встановити та налаштувати плагін XYZ
Захопити стан переключення - вимкнено
Експорт сценарію міграції для: Активувати та налаштувати плагін XYZ
Натисніть кнопку "Експорт" - щоб створити спливаюче текстове поле з відфільтрованим захопленим SQL - в ідеалі попередньо відформатованим як сценарій оболонки з викликом командного рядка до mysql. Скопіюйте та вставте його у папку міграційного коду та додайте до сховища вихідного коду.
Будьте уважні до ввімкнення та вимкнення зйомки під час роботи, і ви зможете генерувати ідеальний сценарій міграції, щоб вивести виробничу базу даних у відповідну конфігурацію вашій базі даних.
Що ще краще, у вас буде сценарій (або серія такого ж), яку ви можете тестувати. Зображення має повторювані, тестовані сценарії міграції !!
Я вже закоханий.
Будь-хто інший?