Делаю большую миграцию в ноду. Полей много, хостинг (друпала, а не источника) не справляется, БД ложится.
Вижу два выхода:
1.
Написать один класс, закомментить лишние запросы. Провести миграцию. После чего раскомментить одно, закомментить другое. Обновить миграцию.
Действенно, но не правильно.
2.
Написать несколько классов. Каждый класс будет отвечать за миграцию определенных полей: содержимое, таксономия, файлы и т.д. в одну и ту же ноду.
Но здесь получается ситуация, при которой каждый класс создает новую ноду.
Собственно вопрос: как можно решить эту проблему? Как заставить классы миграции работать с одной и той же нодой? То есть первый класс миграции создает ноду, второй, третий и т.д. ее обновляют.
И еще вопрос, может есть третье решение?
Ответы
Рабочее время программиста на оптимизацию кода, где-то в тысячу раз дороже ,нежели покупки дополнительных мощностей железа,это факт.
Некоторые программы пишутся уже под определенное железо, и чтобы решить задачу вы должны будете все переписать ,или написать с нуля.
Что касается второй части вопроса - как сделать так, что бы второй класс обновлял материал, а не создавал его заново: У миграции есть такое свойство systemOfRecord. И два допустимых значения: Migration::SOURCE и Migration::DESTINATION. Подробнее про них я как-то писал в статье http://frantsuzzz.com/content/migrate-import-materialov-kak-zhe-ty-vse-t...
Мне кажется хостинг - очень спартанский, надо немного более либеральный найти :)
Что значит "БД ложится"? Из-за чего конкретно ложится?
Я делаю класс миграции.
При попытке его зарегистрировать получаю
Если закомментить часть запросов, то класс отрабатывает без ошибок.
В обсуждении на Друпал.орг пишут, что надо увеличить max_allowed_packet.
Но на хостинге я это сделать не могу.
уменьшите максимальное время выполнения миграции:
Получаю такой ответ:
Не помогает