I'm trying to have a migration that does the following:

  1. Add new nodes
  2. Update existing nodes
  3. Leave unmapped fields that were filled in on the Drupal side untouched

According to [#1117454], I should use Migration::DESTINATION as the system of record to achieve #3. However, I've found out that using the --update flag does all of the above already.

In other issues you've mentioned that this behavior is not intended for the --update flag and that you should indeed use the system of record. Yet here I am using --update and getting exactly what I want. Same goes for my migrated taxonomy terms.

So my questions are:

  • Is the above intended behavior? If not, I risk my migrations breaking all of the sudden when this is "fixed".
  • If it is: what is the difference between --update and Migration::DESTINATION as a system of record?

Comments

kristiaanvandeneynde created an issue. See original summary.

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
CreditAttribution: kristiaanvandeneynde as a volunteer commented

See #1840778-1: Updating migrated entities with a new revision and unmigrated fields causes possible data loss (and other issues) for where you mentioned --update should delete all Drupal-side data. Which is weird somehow, because compared to a rollback scenario the only difference with using --update is the fact that the Drupal-side ids are kept?

The main problem I'm facing is that I can't seem to find any solid documentation on the --update flag.

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
CreditAttribution: kristiaanvandeneynde as a volunteer commented
Issue summary: View changes
mikeryan’s picture

mikeryan
he/him
Primary language English
Location Murphysboro, IL, USA
CreditAttribution: mikeryan at Acquia commented
Status: Active » Postponed (maintainer needs more info)

Any time a migration which does not have system-of-record set to DESTINATION updates a previously-imported item (whether it's via --update, an item updated via highwater marks or track_changes, --idlist, ...), the destination item is rebuilt from scratch and saved with the original destination ID - if any field changed on the destination side gets preserved, that would be a bug.

Do you have any more information on what it is that's getting preserved? What kind of fields, how they were altered, etc?