Closed (fixed)
Project:
Drupal core
Version:
8.3.x-dev
Component:
migration system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
22 Jan 2016 at 17:34 UTC
Updated:
11 Apr 2018 at 17:39 UTC
Jump to comment: Most recent, Most recent file
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 commentedI removed second argument ( !empty($message) )
Comment #22
lomasr commentedComment #23
lomasr 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_emptybut alsoskip_row_if_not_setshould 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 commentedComment #30
gaurav.kapoor commentedComment #32
claudiu.cristea@phenaproxima
Why and where can I found docs about that?
Comment #33
gaurav.kapoor 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::classform.... 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
jofitzRe-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 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