Problem/Motivation

When you have a node migration and run "migrate:import" a second time with the "--update" option it modifies the "changed" value of the node to be the current timestamp and ignores the value from the migration.

Steps to reproduce

Run a node migration.
Run the node migration a second time with the "--update" option.

Proposed resolution

Fix the entity logic so that rerunning a migration does not change the "changed" timestamp if it is specifically defined in the migration (which is usually is).

Remaining tasks

Work out where the fix should go.

User interface changes

n/a

API changes

TBD

Data model changes

TBD

Issue fork migrate_tools-3280140

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

DamienMcKenna created an issue. See original summary.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Related issues: +#3052115: Mark an entity as 'syncing' during a migration update, +#2329253: Allow ChangedItem to skip updating the entity's "changed" timestamp when synchronizing

It was suggested that #3052115 might help, but it didn't. It was then suggested that #2329253 might also help, but it didn't either.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

FYI my migration was based on d7_node_complete.yml and includes the following:

..
source:
  plugin: d7_node_complete
  node_type: something
process:
...
  changed:
    -
      plugin: get
      source: timestamp
...
rclemings’s picture

rclemings commented

FWIW mine is (for the article node type):

...
source:
  plugin: d7_node
  node_type: article
process:
...
  changed:
    -
      plugin: get
      source: changed
...

The combination of #3052115 and #2329253 worked in this case.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

I can confirm along with #4 that the latest core patches from #3052115 and #2329253, combined with a straightforward mapping like the one below resolves the issue where changed timestamp is set to the current time when using drush mim someimport --update.

...
source:
  plugin: d7_node
  node_type: something
process:
  ...
  changed: changed

The d7_node_complete versus d7_node seems like a red herring, and the only practical difference I see (other than the simplified YAML syntax for the "get" plugin) is that Damien was using the source field of timestamp instead of changed.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

I reran the migrations after applying the patches of the two issues and they still don't work as expected with d7_node_complete/timestamp.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

Does it work with d7_node_complete/changed (instead of timestamp)?

Edit: nevermind, just realized node_revision table column name is timestamp.

scotwith1t’s picture

scotwith1t
Location Birmingham, AL
commented

I ran into this and am also having trouble getting it to work even with the 2 patches mentioned. It turns out in my case that adding `validate: true` (#3073707: Migrations can now opt into validation for content entities) was causing this to fail (getting `The content has either been modified by another user, or you have already submitted modifications. As a result, your changes cannot be saved.` error in the migrate_message table for this migration). Just posting this in case the validate flag is a factor for others as well.

jonathan_hunt’s picture

jonathan_hunt commented

fwiw, I found changing from source field timestamp to source field changed worked for me, no patches needed.

josephcheek’s picture

josephcheek
Location Provo, UT
commented

Q: is there any downside to altering the code to configure the code to default to changed: changed instead of changed: timestamp ?

stephane aimar’s picture

stephane aimar commented

So I was aware of something that update the changed date. But thanks to this issue now I know it's when I use --update

But I'm here from this issue https://www.drupal.org/project/drupal/issues/2329253

And someone made a patch for my 10.3.x branche I'm using here https://www.drupal.org/project/drupal/issues/2329253#comment-15705835

With this patch my changed time is not updated with migrate --update

benstallings’s picture

benstallings commented
Version: 6.0.x-dev » 6.1.x-dev
benstallings’s picture

benstallings commented
Status: Active » Closed (outdated)

Since core 11.4.4, issue #3052115, EntityContentBase::save() calls $entity->setSyncing(TRUE) before saving. With that in place, a mapped changed value is kept on --update.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.