MigrateIdMapInterface has saveMessage(), to save per-row notice/warning/error messages to the message table associated with a migration. There is no method on the interface for retrieving them (the closest thing is messageTableName() on the SQL implementation). So, let's add getMessages()...
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | interdiff.txt | 2.61 KB | mikeryan |
| #5 | need_an_api_for-2560435-5.patch | 5.94 KB | mikeryan |
Comments
Comment #2
mikeryanComment #3
mikeryanThe main purpose here would be for tools to provide views of all the messages associated with a migration, but we also (especially for tests) want to be able to retrieve the messages corresponding to a single item (note there can be multiple messages per item). So, I added getMessageIterator($source_id_values = []), which retrieves all messages when the argument is empty.
Comment #4
phenaproximaLooks pretty good to me.
Should be specified as (optional)
\Traversable is the proper type hint here.
getMessageIterator() is a strange method name, can it be getMessages()?
Comment #5
mikeryanActually, I think \Iterator is more on-point.
I think this is consistent with MigrateSourceInterface::getIterator() (specifying getMessageIterator here since the IdMap is an iterator itself over the map table). It's returning an iterator (in practice, SQL query results) rather than the messages directly.
OK, done.
Comment #6
phenaproximaIt freaking prints money!
Comment #7
webchickSo this one I'm a bit less gung-ho about:
1) I don't understand why we have a totally separate logging system in Migrate vs. just using the existing \Drupal::logger(). In IRC, Mike explained this is because you want to store additional properties (such as Migration Source) for easy filtering/debugging purposes.
2) Because it's a separate system, we also don't print these messages anywhere in core, particularly in admin/reports/dblog which is where site builders expect to find status/error messages. (Migrate Upgrade does log messages there, but that's not yet in core.)
3) Awhile back, we also changed watchdog()'s implementation to be PSR-3 friendly. https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logg... The proposed API for this separate logging interface OTOH is a "Drupalism," not inline with those standards.
So 1-2 are basically a "pre-existing condition," so not really a reason to hold up the patch. And I'm not sure if 3 is either, since "by design" we're not building a general-purpose messaging system like watchdog()/\Drupal::logger() are intending to be; this is specific to Migrate (see #1 ;)).
I know this is holding up other things, so I think it's safe to go in, but we should maybe revisit some of these items in follow-ups, esp. with the guidance of a Framework Manager.
For now, committed and pushed to 8.0.x. Thanks!
Comment #9
mikeryanThis is now being used by migrate_plus: #2561455: Implement drush migrate-messages command for D8 migrate.