Add option in MigrateMap to append messages

here's a first pass at something that achieves this

skipping MigrateSQLMap's delete() method is logging lots of undefined hashes in messages:

Undefined property: stdClass::$migrate_map_hash
File .../migrate/includes/source.inc, line 420(file: .../migrate/includes/source.inc, line 420)

still not sure about the implementation, but a usage example with MigrateSQLMap:

    $this->map = new MigrateSQLMap($this->machineName,
      array(
        'YOURKEY' => array(
          'type' => 'int',
          'unsigned' => TRUE,
          'not null' => TRUE,
        ),
      ),
      MigrateDestinationNode::getKeySchema(),
      'default',
      array(
        'track_last_imported' => FALSE,
        'append_messages' => TRUE,
      )
    );

any other plans, or suggestions, for message logging in continuous migrations?

@mike: I’ll try to explain the motivation best i can. I'm using a custom node migration, with system of record of source, using track_changes, and no high water mark. The same migration is used repeatedly (weekly, soon to be daily). Things work fine as they are, except for retaining message logging between migrations.

The imported/unimported counts are getting out of sync, which makes sense per #1732680: removing records from source causes unimported count to be negative. But, more importantly, between re-migrations, Migration class is calling delete() which removes messages prior to each import. In this issue, I was trying to append messages for logging purposes.

// From migration.inc...
// Wipe old messages, and save any new messages.
$this->map->delete($this->currentSourceKey(), TRUE);

Have you ever retained messages, before truncating the table? I've hacked around a bit trying an INSERT INTO to replicate the message and mappings tables, and even tried to register those migrations dynamically with an appended timestamp, like MyMigration_REQUEST_TIME. There were some issues there that i can’t recall specifically, but i beleive having the same sourceid in other mapping tables was creating duplicate nodes from the source.

I talked with moshe in portland and thru conversation, he thought migrate was not really setup for this. But, maybe there's another approach you've already come up with?