Обновление базы данных в разных средах в проекте Joomla3.9 - PullRequest
Новая
       13

Обновление базы данных в разных средах в проекте Joomla3.9

2 голосов
/ 25 июня 2019

Мы работаем над проектом Joomla3.9, работаем в разных средах и используем git в качестве vcs.Так что каждый разработчик работает над своей веткой.Было бы неплохо иметь функцию сравнения базы данных, как в TYPO3 или Contao (посмотрите различия в базе данных после обновления проекта и примените изменения базы данных одним щелчком мыши).Или как система миграции laravel.

Любой разработчик должен легко обновить свою собственную базу данных lokal после того, как изменения базы данных были сделаны из-за обновления расширения через бэкэнд или другого разработчика.И, конечно же, промежуточная или живая система также должна быть легко обновлена.Мы не хотим выполнять sql-скрипты с изменениями в phpMyAdmin.Мы попробовали https://dbv.vizuina.com/.Это не 100% решение.Как будто нет поддержки Cli для запуска процесса миграции с помощью скрипта обновления на сервере.

Кто-нибудь имеет решение или знает расширение, которое может решить эту проблему?Или это можно сделать с помощью основных функций Joomla (может быть, с небольшой корректировкой)?

До сих пор я видел три возможности выполнения модификаций для одной или нескольких таблиц расширений

1: Используйте расширение - контроль версий в таблице схемы.Поэтому добавьте новый sql-файл с увеличенным номером версии по сравнению с номером версии в таблице схемы для этого расширения.Увеличьте также версию в manifest.xml и снова заархивируйте расширение.Переустановите расширение через extension-> manage-> install.Таким образом, будет выполнен новый sql-файл с увеличенным номером версии.

2: как и в предыдущем пункте, но установить расширение через механизм обновления joomla (сервер обновлений).

3 .: создать новый sql-файл в папке sql / расширения.Для нового файла не требуется имя версии, просто update.sql или другое имя файла.Выполните этот скрипт в script.php в методе update (), после того, как расширение будет установлено (в данном случае это обновление) снова.

Третья возможность может быть интересной.Должна быть предусмотрена возможность запуска метода update () с помощью команды / функции cli, чтобы метод мог быть запущен с помощью сценария на сервере.Но как я могу получить информацию, какие скрипты обновления уже были выполнены?Допустим, у меня есть 3 файла обновления в sql-папке.update-1.sql, update-2.sql и update-3.sql.update-1.sql уже выполнен.Поэтому я не хочу снова запускать этот sql-файл - только два других.Таблица схемы используется только с первыми двумя опциями.У меня где-то есть информация, или я должен управлять информацией о том, какие сценарии обновления выполнялись самостоятельно?

1 Ответ

2 голосов
/ 02 июля 2019

Ответ, связанный с версионной базой данных для расширений, зависит от того, являются ли эти расширения тесно связанными с приложением или должны быть для повторного использования и для других приложений.

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

  • История версий приложения может храниться в таблице db_version. Затем оператор вставки добавляется в конце каждого скрипта обновления (добавляя инкрементный номер версии). например

    insert into db_version(version,author,description) values(003,'Verna.Collins', 'removing obsolete column');

  • При условии, что вам необходимо применить миграцию данных к расширениям , также вам необходимо поддерживать таблицу db_version_extensions, в которой хранится история версий для каждый добавочных номеров отдельно . например

    '001' 'extension1', 'Mandy.Aguilar', 'начальная версия'
    '002' 'extension1', 'Mandy.Aguilar', 'добавление дополнительного столбца'
    '001' 'extension2', 'Edna.Potter', 'начальная версия'
    '002' 'extension2', 'Elvira.Townsend', 'удаление неиспользуемой таблицы'
    ..etc

Каждое расширение zip должно содержать сценарий первоначального создания и все файлы sql-update (которые обычно не должны мешать с остальными таблицами приложений ).

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

Теперь, если расширения тесно связаны с приложением , это означает, что они могут использовать / обновлять таблицы приложения. Для расширений этого типа вы можете добавить обновления как часть обновлений приложения . Эти расширения могут даже разрабатываться в том же репо 1067 * и храниться в виде каталогов вместо zip-файлов .

Не уверен, поддерживает ли joomla какие-либо инструменты для автоматизации процесса выполнения инкрементных обновлений БД, но хорошим инструментом является flyway , с портами для командной строки, maven и graddle. Смотрите: как работает пролет

...