Nano Hash - криптовалюты, майнинг, программирование

Используйте одну таблицу миграций Laravel для каждой базы данных

Я работаю в проекте, который использует несколько баз данных. Похоже, что Laravel использует только таблицу миграции в базе данных, которая установлена ​​по умолчанию. Мне нужна одна таблица миграции для каждой базы данных, в которой регистрируются миграции, выполненные в этой конкретной базе данных. Это возможно?

Я определил базы данных в конфигурации следующим образом:

'connections' => [
    'db1' => array(
        'driver'    => 'mysql',
        'host'      => 'db1.host',
        'database'  => 'db1',
        'username'  => 'username',
        'password'  => 'password',
    ),
    'db2' => [
        'driver'    => 'mysql',
        'host'      => 'db2.host',
        'database'  => 'db2',
        'username'  => 'username',
        'password'  => 'password',
    ]
],

Я также сделал первую базу данных (db1) по умолчанию

'default' => 'db1'

Я устанавливаю таблицу миграции в обе базы данных

artisan migrate:install --database=db1
artisan migrate:install --database=db2

После этого я приступаю к созданию пары миграций для конкретной базы данных.

Создайте таблицу test1 в базе данных db1:

use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateTest1Table extends Migration
{
    public function up()
    {
        Schema::connection('db1')->create('test1', function(Blueprint $table)
        {
            $table->increments('id')->unsigned();
        });
    }

    public function down()
    {
        Schema::connection('db1')->drop('test1');
    }
}

Создайте таблицу test2 в базе данных db2:

use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateTest2Table extends Migration
{
    public function up()
    {
        Schema::connection('db2')->create('test2', function(Blueprint $table)
        {
            $table->increments('id')->unsigned();
        });
    }

    public function down()
    {
        Schema::connection('db2')->drop('test2');
    }
}

Теперь я запускаю миграции

artisan migrate

Ожидаемый результат

db1.migrations

+-----------------------------+-------+
| migration                   | batch |
+-----------------------------+-------+
| create_test1_table_in_db1   |     1 |
+-----------------------------+-------+

db2.migrations

+-----------------------------+-------+
| migration                   | batch |
+-----------------------------+-------+
| create_test2_table_in_db2   |     1 |
+-----------------------------+-------+

Фактический результат

db1.migrations

+-----------------------------+-------+
| migration                   | batch |
+-----------------------------+-------+
| create_test1_table_in_db1   |     1 |
| create_test2_table_in_db2   |     1 |
+-----------------------------+-------+

db2.migrations

+-----------------------------+-------+
| migration                   | batch |
+-----------------------------+-------+
Empty set

  • Только что понял, что иметь таблицу миграции для каждой базы данных в отношении откатов может быть плохой идеей. Допустим, у вас есть три базы данных, и последняя миграция вызвала изменения в двух из них. Когда вы хотите откатиться, вы больше не знаете, какие базы данных вам нужно откатить, поскольку больше нет глобального номера пакета. Мысли? 30.10.2014
  • В основном это зависит от ваших потребностей. Если у вас есть одно приложение со структурой хранения данных, распределенной между несколькими серверами (для производительности или по другим причинам), то вам нужен один общий файл миграции. Однако, если у вас есть небольшие приложения/модули, которые могут использовать базы данных только на одном сервере, и вы хотите обновлять их независимо, то было бы полезно иметь отдельные таблицы миграции (имейте в виду, что migrate:rollback также имеет параметр --database). 30.10.2014

Ответы:


1

Используйте параметр --database с командой migrate и сохраните миграции для каждой базы данных в отдельных каталогах.

У вас могут быть отдельные каталоги в app/database/migrations для каждой из ваших баз данных (в вашем случае db1 и db2) и хранить соответствующие миграции в каждом каталоге. Затем вы можете запустить миграцию следующим образом:

artisan migrate --database="db1" --path="app/database/migrations/db1"
artisan migrate --database="db2" --path="app/database/migrations/db2"

Таким образом, ваша таблица migrations будет независимой для каждой базы данных.

Если вы хотите сделать все возможное и автоматизировать процесс, вы можете создать собственную команду, которая будет запускать все миграции одновременно. Вы можете создать такую ​​команду (используйте make:console для Laravel 5.0 до 5.2 или make:command для Laravel 5.2+):

artisan command:make MigrateAllCommand --command=migrate:all

Это создаст новый файл app/commands/MigrateAllCommand.php. Метод fire вашей команды будет выглядеть примерно так:

public function fire()
{
    foreach (Config::get('database.connections') as $name => $details)
    {
        $this->info('Running migration for "' . $name . '"');
        $this->call('migrate', array('--database' => $name, '--path' => 'app/database/migrations/' . $name));
    }
}

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

artisan migrate:all

Вы можете проверить Документацию по командам Laravel для получения дополнительной информации.

30.10.2014
  • Начиная с Laravel 5, следует использовать метод handle() вместо fire(). + Путь должен быть без префикса app/, только 'database/migrations/' . $name 17.05.2019
  • Я написал полную статью для Сэма, вы можете проверить ее по адресу ‹a href=stackcoder.in/posts/ 7.x Несколько подключений к базам данных, миграция, отношения и запросы‹/a› 03.05.2020
  • Новые материалы

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

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..