DDST-376: Fix/requests as content entities #112
Conversation
Given that .installs often need to repeat chunks of schemas in order to manage them, it is somewhat impossible to avoid copypasta.
Had thought at one point that having it split apart might facilitate the migration between config and content, but it turned out not to be necessary.
Expecting the config IDs might need to be reworked to be fully expanded.
Bit of refactoring to account for potential of upstream to vary.
`config_ignore` only works on import: It would not prevent the export and attempts to import of the exported configs on other systems. Instead, Drupal's config transform API allows the config to be dealt with.
| // Create copy of request. | ||
| $config = $config_factory->get($current); | ||
| /** @var \Drupal\islandora_spreadsheet_ingest\RequestInterface $request */ | ||
| $request = \Drupal::entityTypeManager()->getStorage('isi_request')->create([ | ||
| 'label' => $config->get('label'), | ||
| 'machine_name' => $config->get('id'), | ||
| 'sheet_file' => $config->get('sheet')['file'], | ||
| 'sheet_sheet' => $config->get('sheet')['sheet'], | ||
| 'mappings' => $config->get('mappings'), | ||
| 'original_mapping' => $config->get('originalMapping'), | ||
| 'owner' => $config->get('owner'), | ||
| 'active' => $config->get('active'), | ||
| ]); | ||
| $request->save(); | ||
|
|
||
| // Copy ID map and messages tables to the new entities, as those | ||
| // associated with the old should be deleted in the next phase. | ||
| $source_mg_name = "isi__{$config->get('id')}"; | ||
| $dest_mg_name = \Drupal::service('islandora_spreadsheet_ingest.migration_group_deriver')->deriveName($request); | ||
| /** @var \Drupal\migrate\Plugin\MigrationPluginManagerInterface $migration_plugin_manager */ | ||
| $migration_plugin_manager = \Drupal::service('plugin.manager.migration'); | ||
| foreach (array_keys($request->getMappings()) as $name) { | ||
| $source_migration_id = "{$source_mg_name}_{$name}"; | ||
| $dest_migration_id = "{$dest_mg_name}_{$name}"; | ||
| /** @var \Drupal\migrate\Plugin\MigrationInterface $source_migration */ | ||
| $source_migration = $migration_plugin_manager->createInstance($source_migration_id); | ||
| /** @var \Drupal\migrate\Plugin\MigrationInterface $dest_migration */ | ||
| $dest_migration = $migration_plugin_manager->createInstance($dest_migration_id); | ||
| $source_id_map = $source_migration->getIdMap(); | ||
| $dest_id_map = $dest_migration->getIdMap(); | ||
| if (!($source_id_map instanceof Sql)) { | ||
| continue; | ||
| } | ||
| if (!($dest_id_map instanceof Sql)) { | ||
| continue; | ||
| } | ||
|
|
||
| // XXX: Calling Sql::getDatabase() presently initializes things, to ensure | ||
| // that the relevant tables exist. | ||
| $source_id_map->getDatabase(); | ||
| $database = $dest_id_map->getDatabase(); | ||
|
|
||
| $database->insert($dest_id_map->mapTableName()) | ||
| ->from( | ||
| $database->select($source_id_map->mapTableName(), 'm') | ||
| ->fields('m') | ||
| ) | ||
| ->execute(); | ||
| $database->insert($dest_id_map->messageTableName()) | ||
| ->from( | ||
| $database->select($source_id_map->messageTableName(), 'm') | ||
| ->fields('m') | ||
| ) | ||
| ->execute(); |
There was a problem hiding this comment.
This process of effectively recreating the config entities as content entities would work in simple cases; however, given the subsequent derivation of migrate_plus.migration.* entities with the original request entities would have bound the contents of the migrations at that point in time. As a consequence, keys of the migration (and processing within) could have hypothetically changed in the shipped migrations, and so the content entities we are deriving now wouldn't completely represent those original entities.
We could attempt to alter the migrations from these migrate_plus.migration.* entities; however, would be a rather fragile process that is probably not worth the while to implement. Inclined to walk things back, to leave the requests as config entities but mask the entities from import/export using the config transformation API, and so resolving issues with other means of masking the issue (such as our auto-exporting-in-DB "base" split, or introducing config_merge_filter).
There was a problem hiding this comment.
Walking back approach somewhat, proceeding over as #113
No description provided.