Как в Yii2 безболезненно подменить одну таблицу из другой БД?

Question

[Андрей]

Добрый. Извините за корявый язык вопроса.
Пишу app на YII2. Сделал 2 БД. Одну тестовую, которую мучаю, другую которая ведется уже на реальных данных.
Есть таблица с конфигом. При добавлении в одну из БД какой нить новой строки конфига - приходится воссоздавать ее в другой.
Как мне безболезненно вынести подключение к другой БД именно данной таблицы? Таблицу заполняем вручную.
Написано много строк кода и эта таблица используется у меня практически в каждом расчете. Лопатить весь код увы, не хочется.
При беглом чтении мануалов на эту тему, понял, что легче все оставить как есть.

Answer 1

[Denis]

Ответ из SO

return [
'components' => [
    'db1' => [
        'class' => 'yii\db\Connection',
        'dsn' => 'mysql:host=localhost;dbname=db1name', 
        'username' => 'db1username',
        'password' => 'db1password',
    ],
    'db2' => [
        'class' => 'yii\db\Connection',
        'dsn' => 'mysql:host=localhost;dbname=db2name', 
        'username' => 'db2username',
        'password' => 'db2password',
    ],
],
];

QueryBuilder:

Yii::$app->db1->createCommand((new \yii\db\Query)->select('*')->from('tbl_name'))->queryAll();
Yii::$app->db2->createCommand((new \yii\db\Query)->select('*')->from('tbl_name'))->queryAll();

ActiveRecord

public static function getDb() {
    return Yii::$app->db2;
    // return Yii::$app->db1;
}

Comments

[Андрей]

Ну судя по всему придется переписывать все строки чтения из Таблиц и направлять их в нужную БД так ?
Или можно как нибудь это описать в моделях ? чтобы они автоматом читали из нужных ?

[Denis]

Андрей,
Смотря как вы обращаетесь к таблице (в идеале лучше через ActiveRecord, запросы TableName::find()...) тогда Вы навремя тестов указываете в модели AR функцию getDB с нужным подключением, а когда тесты окончились комментириуете ее и выливаете код на боевой сервер

[Иван Шумов]

Андрей, Это все именно в моделях и прописывается. Если у вас вызовы plain SQL то у меня для вас плохие новости и рекомендация хотябы на Query Builder перевести

[Андрей]

Ну я по неумению начал использовать модели только как доступ к таблицам, а почти весь код пишу в контроллере.

Это уже примерно поняв концепцию я начал налегать на модели.
Но и то, PHP кода у меня пока мало. в основном JS

Answer 2

[Иван Шумов]

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

Если же это какая-то внутренняя конфигурация приложения то всплывает два вопроса: почему не миграции и почему вообще не в непосредственно конфигурации.

Если все это не заставляет задуматься то остаётся две вещи: принять факт что тестовая база не должна влиять на прод и то что единственный адекватный вариант получить данные с прода - дамп базы и ее развертывание на тестовый сервер

Comments

[Андрей]

По поводу рук. Прога для внутреннего использования, нас 2-е. И оба понимаем что делаем. По поводу безопасности - вообще не заморачивались.
У нас Копи Центр и в конфиг пишем разную внутреннюю инфу для проги. ( цены , данные для расчетов итд итп.)
По поводу миграции - база на FireBird , и на Web я переезжаю с Lazarus.
Я не программист, учил сам все с 0 практически.
Ну коль в данном вопросе возникают сложности, то придется наверно помучатся.

[Иван Шумов]

Андрей, вас больше нуля и вы не понимаете что делаете именно по тому что не программист и практически с нуля. У вас уже проблема ив поддержке, а вряд ли там проект большой.

Базу тоже всегда можно мигрировать если она больше ни к чему не приколочена

[Андрей]

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

[Иван Шумов]

Андрей, миграции это хорошо. Только надо понимать когда их стоит применять, а когда нет

[vitaly_74]

Андрей, не слушайте этого гения)) ответ сверху достаточно хорош.

[Андрей]

У меня тут вопрос созрел. Я уже пытался по пьяне поразмышлять по этому поводу, но к выводам мы не пришли.
Суть в чем. На серверной части проекта существуют точки входа ( actions ) к которым обращается клиентская часть. По крайней мере у меня все организовано именно так. У меня их много. Например на главной странице 3 таблици, пару графиков. Обращаюсь через ajax на 5 actions.

Правильно ли у меня организована логика ? или существуют "правильные" методы?

[Иван Шумов]

Андрей, Ничем плохим это не является, но если хочется уменьшить число запросов то можно сделать методы-агрегаторы или поставить GraphQL сервер. На ранних стадиях проекта не стоит так заморачиваться. Вот когда число запросов вырастет в десятки и поддерживать это станет тяжело - стоит задуматься

[Дмитрий]

Андрей, миграции правильный подход. Но только для изменения структуры таблиц, а не для изменения данных.

[Андрей]

Дмитрий, В данном случае именно данные. тИбо структура поддерживается ( хотя уже матюкатся начинаем ибо запрос долго обрабатывается ) уже 5 лет.

[Андрей]

Иван Шумов, Спасибо. меня кстати это очень волновало.

[Дмитрий]

Андрей, миграции не для изменения данных в таблице.

Answer 3

[Александр Вербицкий]

return [
'components' => [
    'db2' => [
        'class' => 'yii\db\Connection',
        'dsn' => 'mysql:host=localhost;dbname=db2name', 
        'username' => 'db2username',
        'password' => 'db2password',
    ],
],
];

QueryBuilder:

(new \yii\db\Query)->select('*')->from('tbl_name')->createCommand(Yii::$app->db2)->queryAll()