Міграція за допомогою модуля міграції

Я використовую Drupal 7 та останній модуль Migrate. Я намагаюся створити клас для міграції продуктів з БД OpenCart на мій новий сайт D7. Я розібрався з усім необхідним SQL і отримав більшу частину програми, яку я запрограмував. Але у мене виникають невеликі проблеми з розумінням того, як я збираюся робити категорії.

Моя міграційна місія - Ubercart.

Що я намагаюся зрозуміти, сидить у модулі migrate_example, який є підмодулем Migrate. Зокрема, я переглядаю файл wine.inc у класі WineWineMigration. Я намагаюся зрозуміти термін міграція.

У мене є два списки, які стануть термінами систематики в продуктах Ubercart. По-перше, це категорії. Я налаштував категорії вручну, тому коли я приведу список тих, хто закінчився (використовуючи функцію GROUP_CONCAT SQL), у мене з'явиться купа ідентифікаторів, які я буду картати за допомогою масиву, який буде містити всі перетворення ідентифікаторів. Це добре, але коли я переглядаю їхню інформацію про BestWith, що вони мігрують, це показує, що він використовує клас WineBestWith вище для імпорту терміна.

Мене це бентежить, бо це схоже на якусь вторинну міграцію термінів. Це те, що відбувається? Далі, тут я би помістив свій масив картографування у цей термін міграційного класу?

Наступне, що мені потрібно зробити - це розібратися з тегами. У OpenCart у нас є купа безкоштовних тегів форм. І коли я створюю продукт вручну в Ubercart, у мене з'являється поле для автозаповнення тегів. У цьому полі я можу просто помістити список відокремлених комами, і це створює кілька термінів. Чи можу я зробити те ж саме в модулі Міграція? Чи можна просто відобразити поле до списку розділених комами термінів? Чи додасть теги до кожного продукту?

Я зараз працюю над тією ж проблемою, щоб зрозуміти вашу плутанину. У вас є багато питань, але я думаю, що їх можна підсумувати в єдине запитання:

Як модуль Migrate обробляє міграцію нормалізованої бази даних в установку Drupal?

Це, безумовно, не просто, але ось моє розуміння того, як це працює. Ми почнемо з вершини (WineWineMigration), що йде вниз, і задаватимемо питання, як йдемо.

Ми починаємо, дивлячись на код у верхній частині WineWineMigrationкласу.

...
$this->dependencies = array('WineVariety', 'WineRegion',
  'WineBestWith', 'WineUser', 'WineProducer');
...

Це говорить про модуль Migrate, що для міграції вашого вмісту Wine, спочатку слід завершити залежні міграції - WineVariety, WineRegion, WineBestWith, WineUser, WineProduce.

Отже, ми тут дізналися, що міграція може залежати від інших міграцій .

Далі ми маємо відображення між таблицею, в якій зараз міститься інформація про базове вино, та вузлом Drupal:

$this->map = new MigrateSQLMap($this->machineName,
  array(
    'wineid' => array(
      'type' => 'int',
      'unsigned' => TRUE,
      'not null' => TRUE,
      'description' => 'Wine ID',
      'alias' => 'w',
    )
  ),
  MigrateDestinationNode::getKeySchema()
);

Це досить просто, тому якщо вам потрібно роз'яснення, я його надам.

Я збираюся пропустити деякі проміжні речі, які не дуже доречні для підключення різних категорій та предметів вина.

Тепер ми переходимо до відображення полів. Дотримуйтесь:

// Mapped fields
$this->addFieldMapping('title', 'name')
     ->description(t('Mapping wine name in source to node title'));
$this->addFieldMapping('uid', 'accountid')
     ->sourceMigration('WineUser')
     ->defaultValue(1);
// TIP: By default, term relationship are assumed to be passed by name.
// In this case, the source values are IDs, so we specify the relevant
// migration (so the tid can be looked up in the map), and tell the term
// field handler that it is receiving tids instead of names
$this->addFieldMapping('migrate_example_wine_varieties', 'variety')
     ->sourceMigration('WineVariety')
     ->arguments(array('source_type' => 'tid'));
$this->addFieldMapping('migrate_example_wine_regions', 'region')
     ->sourceMigration('WineRegion')
     ->arguments(array('source_type' => 'tid'));
$this->addFieldMapping('migrate_example_wine_best_with', 'best_with')
     ->separator(',')
     ->sourceMigration('WineBestWith')
     ->arguments(array('source_type' => 'tid'));
$this->addFieldMapping('field_migrate_example_wine_ratin', 'rating');
$this->addFieldMapping('field_migrate_example_top_vintag', 'best_vintages');

Подивіться, де написано:

->sourceMigration(...)

Це вказує на міграцію, що для відображення цього поля спочатку потрібно виконати іншу міграцію. Я вважаю, що це "вторинна міграція", про яку ви говорили. Скористаємося regionкартографічним полем як приклад тут. Розбивши його ...

$this->addFieldMapping('migrate_example_wine_regions', 'region')
     ->sourceMigration('WineRegion')
     ->arguments(array('source_type' => 'tid'));

Це говорить про те, що область категорії у базі даних джерела відображається на термін словникового запасу регіону. Як зазначається в коментарі до TIP в фрагменті кодового відображення поля, він передбачає, що відображення зроблені на основі імен field_name, але оскільки ми залежні від вторинної міграції, як ви це сказали, нам потрібно вказати міграцію, від якої вона залежить, і доручити їй використовувати поле замість назв полів.

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

Я сподіваюся, що це допомагає. Я сам не цілком розумію це питання, тому я використав це питання як можливість покращити своє розуміння того, як Міграція стосується баз даних. Оскільки я дізнаюся трохи більше, я відповідно оновлю відповідь.