Mark an entity as 'syncing' during a migration update

Created on 2 May 2019, over 5 years ago
Updated 22 March 2024, 9 months ago

Problem/Motivation

There is an unmet need to flag entities as "syncing" when doing migration updates, so that they can be handled differently from ordinary updates.

For example, updating an entity sets the entity's changed time to the current time. This creates an issue when doing migration updates, which update entities on the destination that have been changed on the source since the last migration.

In an initial migration, the entity's changed time is set to match the changed time in the data source. For example, if a node of the page content type has a "changed" timestamp 1651775012 in the source, the node will also have a "changed" timestamp 1651775012 in the destination, regardless of how much time has actually elapsed since then.

This behavior should be the same when the initial migration is updated (via e.g. "drush mim upgrade_d7_node_page --update"). But it's not. Rather, the "changed" timestamp on the destination entity is set to the current time, instead of the value of the "changed" timestamp on the source node. As a result, the migrated data on the destination does not faithfully mirror the source.

Among other side effects, views that include a sort on the entity's changed time may not work correctly on the destination after a migration update.

An additional example of the need for a "syncing" flag can be seen in issue #2803717: Allow 'syncing' content to be updated in content moderation without forcing the creation of a new revision β†’ , concerning updates in content moderation.

Proposed resolution

Multiple patches are involved. This one simply flags an entity as "syncing" during a migration.

The following pending patch looks for the "syncing" flag and skips updating the changed time for entities with that flag:

πŸ“Œ Allow ChangedItem to skip updating the entity's "changed" timestamp when synchronizing Fixed
This fixed issue uses a "syncing" flag to solve a similar problem in content moderation migrations:

#2803717: Allow 'syncing' content to be updated in content moderation without forcing the creation of a new revision β†’
Blocked on:

None. This patch simply sets the "syncing" flag that can be used to alter the behavior of an entity migration. It is blocking πŸ“Œ Allow ChangedItem to skip updating the entity's "changed" timestamp when synchronizing Fixed and would provide a simpler method to implement #2803717: Allow 'syncing' content to be updated in content moderation without forcing the creation of a new revision β†’ .

Steps to reproduce

See the steps in the issue #3195139: migrate:import --update creates new revisions, if content_moderation active β†’ because the current one will fix it automatically

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

This patch marks entities as "syncing" during migrations, so that other code (including issues πŸ“Œ Allow ChangedItem to skip updating the entity's "changed" timestamp when synchronizing Fixed and #2803717: Allow 'syncing' content to be updated in content moderation without forcing the creation of a new revision β†’ ) can alter the handing of migrating changes to entities.

✨ Feature request
Status

Fixed

Version

11.0 πŸ”₯

Component
MigrationΒ  β†’

Last updated 3 days ago

Created by

πŸ‡¦πŸ‡ΊAustralia Sam152

Live updates comments and jobs are added and updated live.
  • Contributed project blocker

    It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024