Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
There are certain types of dynamic migrations that may need access to the original data values in order to prepare source data. Examples include:
- Dynamically identifying some source properties based on the values of other source properties.
- Dynamically setting the value of some source properties based on original values that do not need migration.
In my case, I have a very custom migration which is deriving the node bundle based on a property of the entity, which means I need the original values on the data so I can dynamically set which fields I will be supporting based on the destination bundle definition.
Proposed resolution
Add a flag to Data Parser plugins to support a new include_raw_data configuration of the source plugin. When present, the full set of original values for the row will be included as a "raw" element of the Row object. By defaulting this to not happen we minimize the memory impact for the majority of use cases that will not need this functionality.
Remaining tasks
A patch with an implementation for the data_parser is forthcoming. A generic treatment of this that can live in DataParserPluginBase would be ideal.
User interface changes
N/A
API changes
None.
Data model changes
Configuration addition.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | add_support_for_original_data-2780965-2.patch | 1.73 KB | Grayside |
Comments
Comment #2
Grayside CreditAttribution: Grayside at Phase2 for Norwegian Cruise Line commentedAttached patch provides initial working support for the JSON data parser as mentioned in the description. Since this seems like it should cover all data parsers instead of just a single plugin I'm setting this to Needs Work.
Comment #3
Grayside CreditAttribution: Grayside at Phase2 for Norwegian Cruise Line commentedSince #2792765: Allow XML elements to pass through as field values to process plugins was acceptable for a specific format, let's recast this one as JSON-specific
Comment #5
mikeryanLooks good - if we decide we want to support this pattern for XML (in addition to the automated this-is-not-a-string-so-pass-it-through), we can do that when the need arises.