Option to suppress notices

Here is a way for me to implement this myself, by overriding the parent class. However, since the severity level constants can not be distinguished from drupal level severity constants (since they share integer values in some cases), the implementation is much more limited and primitive than it should be:

<?php
  /**
   * Pass messages through to the map class.
   *
   * We are overriding the default behavior here since we don't want
   * ALL watchdog notices or alerts to be placed in the migrate
   * message tables, but only important ones.
   *
   * @param string $message
   *  The message to record.
   * @param int $level
   *  Optional message severity (defaults to MESSAGE_ERROR).
   */
  public function saveMessage($message, $level = MigrationBase::MESSAGE_ERROR) {
    switch ($level) {
      case MigrationBase::MESSAGE_ERROR:
      case MigrationBase::MESSAGE_WARNING:
      case WATCHDOG_EMERG:
      case WATCHDOG_ALERT:
      case WATCHDOG_CRITICAL:
      case WATCHDOG_ERROR:
      case WATCHDOG_WARNING:
        parent::saveMessage($message, $level);
        break;
      default:
        Migration::displayMessage($message);
        break;
    }
  }

?>

The problem with my approach is this:

<?php
/* The WATCHDOG_* constant definitions correspond to the logging severity levels
 * defined in RFC 3164, section 4.1.1: http://www.faqs.org/rfcs/rfc3164.html */
define('WATCHDOG_EMERG', 0);
define('WATCHDOG_ALERT', 1);
define('WATCHDOG_CRITICAL', 2);
define('WATCHDOG_ERROR', 3);
define('WATCHDOG_WARNING', 4);
define('WATCHDOG_NOTICE', 5);
define('WATCHDOG_INFO', 6);
define('WATCHDOG_DEBUG', 7);

const MESSAGE_ERROR = 1;
const MESSAGE_WARNING = 2;
const MESSAGE_NOTICE = 3;
const MESSAGE_INFORMATIONAL = 4;

?>

In other words, a WATCHDOG_ERROR (3) is the same as a MigrationBase::MESSAGE_NOTICE, and there is no way for me to distinguish between the two in my code.

So I'm tempted to change this to a bug report along the lines of: Ensure Migrate module also follows RFC 3164 in defining its severity levels, OR ensure Migrate module uses a non-clashing set of integer values so that users can distinguish between severity levels that are WATCHDOG error levels and which are MigrationBase messages.

It seems to me the patch would be one of two things, depending on implications (need input from maintainers here, I think):

Either my patch will be:

<?php
const MESSAGE_ERROR = 3;
const MESSAGE_WARNING = 4;
const MESSAGE_NOTICE = 5;
const MESSAGE_INFORMATIONAL = 6;
?>

or something like:

<?php
const MESSAGE_ERROR = 1000;
const MESSAGE_WARNING = 2000;
const MESSAGE_NOTICE = 3000;
const MESSAGE_INFORMATIONAL = 4000;
?>

The weakness of approach 1, is that migrate module will have to continually adjust to drupal's watchdog levels (although since they're tied to an RFC, I don't think that's a big issue).

The weakness of approach 2 is that it's an ugly, non-failsafe kludge :-)

but I don't think ignoring notices should be the default behavior.

I agree with you mikeryan. I'm trying to deal with several contributed modules (whose source code I don't control) who send out watchdog() calls all over the place, some for good reason, and most for no good reason at all. If the module developers would have set the $severity param to DEBUG, things would be easier, but they often just call watchdog() with no $severity param attached.

Which means, in the specific case I'm dealing with, that I get 20+ rows in my migrate_message_* table per item migrated. If I migrate a thousand items, I have 20,000 new rows in that table... most of it sheer junk. This is where the noise actually starts to obscure any utility the migrate_message_* tables have. At this point, there is so much junk data in there, I don't even want to look at them.

Since I can't control what contributed modules are doing with watchdog, and since migrate module is hooking into watchdog rather than relying on its own logging system, I need to be able to silence the messages that are actually not relevant to the migration task at hand.

In the end, I managed to do this without modifying any migrate code, so will paste my eventual solution in here as documentation in case someone else is also fighting their way through tons of watchdog notices being thrown into migrate_message_* tables.

In my basic migration class (extends Migration, and is the parent for my specific migration classes), I ended up doing this:

<?php
  public function saveMessage($message, $level = MigrationBase::MESSAGE_ERROR) {
    switch ($level) {
      case MigrationBase::MESSAGE_ERROR:
      case MigrationBase::MESSAGE_WARNING:
        parent::saveMessage($message, $level);
        break;
      case MigrationBase::MESSAGE_NOTICE:
        Migration::displayMessage($message);
        break;
      default:
        // Ignore INFORMATIONAL messages unless verbose mode is
        // enabled.
        if (function_exists('drush_get_context') && drush_get_context(DRUSH_VERBOSE)) {
          Migration::displayMessage($message);
        }
        break;
    }
  }
?>

FYI, drush already lets user control this. Perhaps migrate could honor drush's global option?

This strikes me as the "correct" way to move forward. I was, I see now, already kind of moving in that direction by making my code listen to the drush --verbose option. Responding to the drush --watchdog=log|print|disabled option might be even better.

The only thing we lose here, of course, is that this is specific only to running migrations from the command line.

--watchdog Control logging of Drupal's watchdog() to drush log. Recognized values are 'log', 'print', 'disabled'. Defaults
to log. 'print' shows calls to admin but does not add them to the log.

A real world test, however, brings no joy. Using --watchdog=disabled does absolutely nothing to suppress the hundreds of watchdog entries from other modules being spit out during a migration. Many of the messages originate in watchdog() calls, but many of them are also the output to drupal_set_message going to the terminal.

The only thing that works is --quiet, which, however, has the unfortunate side effect of silencing all output except the output from --instrument.

Doing this helped silence the output from other modules' drupal_set_message calls....

/**
   * Implements Migration->postImport();
   */
  public function postImport() {
    // Get rid of any drupal_set_message output from modules so we
    // don't clutter a drush-initiated migration.
    if (function_exists('drush_get_option') && !drush_get_option('verbose')) {
      drupal_get_messages(NULL, TRUE);
    }
    parent::postImport();
  }