Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Processors skip_on_empty
and skip_row_if_not_set
are not logging any message when they are skipping rows. But such information is very useful for content managers.
Proposed resolution
Allow skip_on_empty
and skip_row_if_not_set
processors to specify a customized message to be logged when a row is skipped.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
New message
configuration in skip_on_empty
and skip_row_if_not_set
plugins.
Comment | File | Size | Author |
---|---|---|---|
#39 | 2655154-39.patch | 6.22 KB | jofitz |
#35 | interdiff-30-to-35.txt | 6.23 KB | claudiu.cristea |
#35 | 2655154-35.patch | 6.2 KB | claudiu.cristea |
Comments
Comment #3
mikeryanThe migration message table is the logical place for row-specific messages like this. Should be fairly simple - where MigrateSkipRowException is caught, do a $this->idMap->saveMessage(). And of course anything that throws MigrateSkipRowException should be giving it a message...
Comment #4
generalrednecklooks like it may be as simple as this... though we may want to have a different message level for skipped messages... but the default for all Migration Exceptions is MigrationInterface::MESSAGE_ERROR.
Comment #6
generalredneckOk my bad... for some reason I thought MigrateSkipRowException extended the MigrateEsception... Fixed the level to use MigrateIdMapInterface::STATUS_IGNORED
Comment #7
generalredneckComment #8
mikeryanLet's skip this when the message is empty, no point in cluttering the message table with empty messages.
A test would be good.
Comment #10
generalredneck@mikeryan
I need a little help. I've figured out how to test the migration and added a little bit to the MigrateSkipRowTest. The challenge I'm facing is how to grab the message that is being pushed to MigrationExecutable::saveMessage(). This ultimatly calls the MigrateIdMapInterface class... which the instance class in this case is Drupal\migrate\Plugin\migrate\id_map\Sql. This is a problem since I don't think I can do an $this->installSchema() with dynamically created tables... maybe you can help me there... BUT I think the right way to handle this is to use the Event Dispatcher called by line 639 on that class.
My problem is I don't know how to hook into the eventDispatcher... if you can point me in the right direction... I'll update one of the test modules to pick it up and we can verify the test this way by saving the messages since they aren't ever stored (except in the database) using Drupal\migrate\Plugin\migrate\id_map\Sql::saveMessage()
Comment #11
generalredneckAnd then I got to thinking...
The Drupal\migrate\Plugin\migrate\id_map\Sql class probably would have errored out if the table didn't exist... as there is no checking for it. I see that the table is created on the fly. I'll just check that. :P
Comment #12
generalredneckAdded tests (both unit and Kernel) to test the changes I made. I added messages to SkipOnEmpty unless you add a quiet configuration. That's tested here as well. I also added logging messages for "prepareRow" as that wasn't the case before (as the tests pointed out to me).
Comment #13
mikeryanComment #14
mikeryan@generalredneck: I'm very sorry I didn't get back to this issue more promptly, or immediately recall it when getting involved with reviewing #2818871: Allow logging skip row exception messages - that issue covers much of your work here (with identical code - you deserve an issue credit on that). For what it's worth, on today's migrate maintainer call we discussed doing a better job of keeping up with the "Needs review" issues for the migration system so patches don't languish - we formally parceled out the oldest (least-recently-updated) in the queue, which is how I came back to this one. We should do better going forward.
Having an option to log the skip_on_empty process plugin is still a good idea, though - you'll need to reroll due to the redundant changes in the other issue.
I think a "log_message" configuration option (with the opposite sense) would be more clear, with the default in its absence being not to log (maintaining the current behavior and not surprising people with messages they weren't expecting).
Comment #15
generalredneckI had the same thought after I made the patch but I though I woudl see what you said. I'll get us an update.
Comment #16
generalredneckComment #18
mikeryanWeird, I don't see why this patch would introduce requirements failures - retesting.
Comment #20
mikeryanHere's the problem - remove the second argument, we should *always* record the skip in the map table.
Comment #21
olegel CreditAttribution: olegel as a volunteer commentedI removed second argument ( !empty($message) )
Comment #22
lomasr CreditAttribution: lomasr at gai Technologies Pvt Ltd for gai Technologies Pvt Ltd commentedComment #23
lomasr CreditAttribution: lomasr at gai Technologies Pvt Ltd for gai Technologies Pvt Ltd commentedComment #24
mikeryanMain patch looks good, just a couple of test tweaks...
The second line should be indented. Although, actually, I think it would be cleaner to assign to SkipOnEmpty plugin to a variable and call transform on the variable.
Please use a 'use' statement for the exception and reference it as simply MigrateSkipRowException.
Comment #25
mikeryanComment #27
claudiu.cristea+1 for this feature, but:
skip_on_empty
but alsoskip_row_if_not_set
should benefit from this.Redefining the IS according to these considerations.
Comment #28
phenaproximaOh, but this is a great idea. The patch looks good. My concerns are nitpicks, code standards, and documentation-related.
The last sentence seems a bit unclear. And can the second-to-last sentence read "Messages are only logged for the 'row' skip level"?
s/log/logs
The last sentence is phrased strangely. Maybe "is missed" should be "if not set"?
This should end with "and the message "Missed the 'data' key" will be logged".
I have recently been informed that we need to use $this->setExpectedException() in the test method, rather than the annotation.
Same here.
And here.
And here.
Comment #29
gaurav.kapoor CreditAttribution: gaurav.kapoor at OpenSense Labs commentedComment #30
gaurav.kapoor CreditAttribution: gaurav.kapoor at OpenSense Labs commentedComment #32
claudiu.cristea@phenaproxima
Why and where can I found docs about that?
Comment #33
gaurav.kapoor CreditAttribution: gaurav.kapoor at OpenSense Labs commentedThere is an issue regarding this https://www.drupal.org/node/2822837 , but it has been postponed. So should we use method $this->setExpectedException() ?
Comment #34
claudiu.cristeaIndeed, a Coder policy is prepared in #2859286: Forbid @expectedException @expectedExceptionMessage.
All these annotations should be removed and $this->setException() should be before the point where the exception is expected. Also you'll need to pass the expected message. Use the
MigrateSkipRowException::class
form.... and logs the message 'Field...
Replace "If is missed... " with "If not set, nothing is logged in the message table."
Unrelated changes. Revert them.
Comment #35
claudiu.cristeaFixed #34.
Comment #36
phenaproximaMethinks it's ready. Thanks!
Comment #38
claudiu.cristeaComment #39
jofitz CreditAttribution: jofitz at ComputerMinds commentedRe-rolled.
Comment #40
claudiu.cristeaIt's only a reroll, so back to RTBC.
Comment #42
claudiu.cristeaComment #44
claudiu.cristeaComment #45
alexpottAs this is a non breaking API addition to and experimental module backported to 8.3.x.
Committed and pushed e53654a to 8.4.x and bf80ef2 to 8.3.x. Thanks!
I discussed with @mikeryan today and he convinced me that this will be a useful change. We also discussed the possible of following up with a verbose switch to report all skipped rows.
Comment #49
rajeevku CreditAttribution: rajeevku commentedThis one never works , throws exception but doesn't log anything.
Comment #50
heddndrush mmsg %migration_id%
should give you log results. If it doesn't, please open a new issue to investigate the regression.Comment #51
dwwDear people who added this cool feature:
a) Thanks!
b) RFC: #2960204: Make it possible for optional log messages from *skip* process plugins to contain context
Cheers,
-Derek