Миграция с модулем миграции

Я использую Drupal 7 и последний модуль Migrate. Я пытаюсь создать класс для переноса продуктов из базы данных OpenCart на мой новый сайт D7. Я разобрался со всем необходимым мне SQL и запрограммировал большую часть этого. Но у меня возникли небольшие проблемы с пониманием того, как я собираюсь делать категории.

Моя цель миграции - Ubercart.

То, что я пытаюсь понять, находится в модуле migrate_example, который является подмодулем Migrate. В частности, я смотрю на файл wine.inc в классе WineWineMigration. Я пытаюсь понять термин миграция.

У меня есть два списка, которые станут терминами таксономии в продуктах Ubercart. Во-первых, это категории. Я настроил категории вручную, поэтому, когда я приведу их список (используя SQL-функцию GROUP_CONCAT), у меня будет набор идентификаторов, которые я буду отображать, используя массив, который будет содержать все преобразования идентификаторов. Это хорошо, но когда я смотрю на их информацию BestWith, что они переносятся, это показывает, что он использует класс WineBestWith выше для импорта термина.

Я смущен этим, потому что это похоже на некоторую вторичную миграцию терминов. Это то, что происходит? Кроме того, это где я бы поместил свой массив сопоставления, в этот термин класс миграции?

Следующее, что мне нужно сделать, это разобраться с тегами. В OpenCart у нас есть куча тегов свободной формы. И когда я вручную создаю продукт в Ubercart, у меня есть поле автозаполнения для тегов. В этом поле я могу просто поместить список терминов, разделенных запятыми, и он создаст несколько терминов. Могу ли я сделать то же самое в модуле Migrate? Могу ли я просто сопоставить поле со списком терминов, разделенных запятыми? Будет ли это добавить теги для каждого продукта?

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

Как модуль 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 в блоке кода сопоставлений полей, предполагается, что сопоставления сделаны на основе имен полей, но, как вы выразились, мы зависим от вторичной миграции, нам нужно указать миграцию, от которой она зависит, и дать ей указание: используйте приливы вместо имен полей.

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

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