Closed (fixed)
Project:
Migrate
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
30 Jan 2012 at 22:48 UTC
Updated:
8 Apr 2014 at 20:15 UTC
Jump to comment: Most recent
Is there an established way of saving messages about the current record when you are in a prepareRow function? When skipping over rows due to bad data, it would be good to provide the user with an explanation.
I tried saving a migration message using the $this->saveMessage function, and the message was saved, but with the wrong source id. Apparently, $this->currentSourceKey is not set until it gets to the actual import function, and so when you save messages in the prepare row function, it uses the value of the previous record.
Thanks!
Comments
Comment #1
mikeryanWe should probably replace the Migration class $currentSourceKey with a function calling through to $this->source->getCurrentKey().
Comment #2
mikeryanComment #3
mikemccaffreyIt doesn't seem to just be an issue with knowing the key. It looks like messages are cleared at the beginning of the import() step, after all of the prepareRow functions are called, so even if the ID was known in the prepare phase, the messages would be cleared right afterwards.
Perhaps we could move that message clearing to the beginning, as soon as the migration is called? In the meantime, I added some custom functions to my migration class to save messages from the prepareRow functions and add them during the import phase:
Comment #4
David_Rothstein commentedI just ran into this problem and @mikemccaffrey's code worked perfectly for me (thanks Mike!).
I also agree that moving the message clearing earlier sounds like a good way to fix this.
Comment #5
mikeryanOK, I've added a queueMessage() method (same parameters as saveMessage()) along the lines of the approach above.
Comment #7
joachim commentedSo is it the case that saveMessage() can't be used in prepareRow()?
Should queueMessage() be used there instead? Should it always be used? Because having two different methods to record a message depending on where you are in the code seems rather complicated to me.
At the very least this needs documenting -- I just spent 15 minutes trying to figure out why my messages don't work.
Comment #8
mikeryanPlease don't reopen long-closed issues - open a fresh support request if you have a question relating to something that's already been committed.
That being said, the semi-redundant methods are because rearranging the main processing loop so saveMessage() would work in prepareRow() would mess with the existing sequence of events - I didn't see a way to do it without breaking something else, or doing some risky refactoring. queueMessage() should work fine wherever saveMessage() is used.
I added a note to #1965854: Update documentation for Migrate 2.6 to document queueMessage().