Closed (duplicate)
Project:
Drupal core
Version:
8.0.x-dev
Component:
migration system
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
18 Feb 2015 at 20:52 UTC
Updated:
4 Aug 2015 at 15:27 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
nicoloye commentedTrying to understand the global structure of our new migrate module, so sorry if the logic is wrong, I'm still novice on D8 ;)
Here is a patch, c&c are welcome.
Surely needs more work.
Currently the states are saved with this name : "migrate_last_imported:[migration id]", maybe another naming convention should be used ?
Comment #2
nicoloye commentedComment #4
mikeryanHere you're setting it where another migration is checking to see if this migration has completed at some time in the past. The place to set it would be at the point the migration actually finished running. The return points in MigrateExecutable::import() would be the place to do that.
We're saving other similar information using keyvalue rather that state - see https://www.drupal.org/node/2429085#comment-9829053 - I think this should be consistent with the others.
I don't think the API should do the formatting, that should be left to the caller (just return the timestamp).
A little too much pasted here.
Comment #5
nicoloye commentedOops, sorry for that, I'll check this tomorrow. Thanks for the feedback :)
Comment #6
nicoloye commentedHere is a fixed patch.
Comment #7
mikeryanStill looking for that change from state to keyvalue - see the previously-linked issue and the current patch using keyvalue: https://www.drupal.org/files/issues/track_current_state_of-2429085-13.patch
There are a couple of error returns in this function, I think we should track the time there as well.
Looking good - I've got a migrate_plus patch using this at #2429107: Display last imported time with drush migrate-status:
Comment #8
mikeryanComment #9
nicoloye commentedAh, I may have missed it. I'll fix this.
Comment #10
anavarre@nicoloye if you could also post an interdiff with new patches, that would be great. Thanks!
Comment #11
nicoloye commented@anavarre, I'll do that, no problem :)
Comment #12
nicoloye commentedHere is a new patch & interdiff.
@mikeryan, for some reason
drush msreturns nothing on my local install. I tried importing stuffs through migrate_drupal ui or manifest file but maybe it's not the right way, how can I test this ?Comment #13
mikeryanDid you enable migrate_example? That's what provides the migrations for testing.
Also note that for now you need to add
to your settings.php (pending group support getting committed).
Comment #14
nicoloye commentedOK so the values are wrongly saved.
I can't figure what I've done wrong, I compared these changes with other keyValue entries in the module and I don't see much differences.
Comment #15
mikeryanOops - you're returning the keyvalue store rather than the value returned by get().
Comment #16
nicoloye commentedOuch, how could I miss that ... ^^"
Comment #17
nicoloye commentedHere it should be good.
Comment #18
mikeryanOK, my previous statement was a little broad - since the requirements exception is preventing import from happening at all, I would say we should not set the last imported time here.
With the removal of that line, I'll be ready to declare this rtbc. Thanks!
Comment #19
nicoloye commentedThanks ! I removed the time tracking for requirements exceptions.
Comment #22
mikeryanComment #25
anavarrePer #22
Comment #26
xjmThis seems like a great idea, and the implementation is nice and clean. Needs tests though.
Minor, but is there a reason that we're not injecting the KV store dependency?
Should we add an optional parameter to set a specific time? If we don't want to make that functionality public, we could at least make this protected and add a public wrapper like
setLastImportedNow()... or something like that with a better name.Also, isn't it normal for most setters to return
$this? I could be mistaken.Very minor: Should be "Gets" and "Sets" per https://www.drupal.org/node/1354#functions.
Comment #27
mikeryanAt the moment, the plan is for this to be accomplished by #2535458: Dispatch events at key points during migration.
Comment #28
mikeryanContrib can do this itself now: https://www.drupal.org/node/2544874