Problem/Motivation

Over in #2427335: Combine legacy Source class into SourcePluginBase we combined the legacy Source class with SourcePluginBase. We needed to add a public property to SourcePluginBase for the executable but we should find a better way to handle this dependency.

Proposed resolution

Inject the executable without putting the migration into a state where it sometimes has the executable. Maybe just injecting the executable into the migration when it's constructed.

Remaining tasks

Discuss, write patch

User interface changes

n/a

API changes

possible

Comments

mikeryan’s picture

Ran across this today while messing with prepareRow(). The real question is, why does the source plugin need MigrateExecutable? I see it being used for two things:

  1. $this->migrateExecutable->rollbackAction - Since we're saving a map row with no destination ID, the rollback action is entirely irrelevant and should simply be omitted from the saveIdMapping call.
  2. $this->migrateExecutable->saveQueuedMessages() - Maybe the Migration class should be dealing with the messages instead of MigrateExecutable? Or, take a close look at the message-queuing business, which was always a bit hackish...
benjy’s picture

Yes I think we brought it across from the legacy "Source" class that was using this: $this->migrateExecutable->saveQueuedMessages();

Right now the executable handles saving for good rows and the source for rows we're skipping, we should make this the responsibility for the executable alone but I don't know how easy that is going to be.

mikeryan’s picture

Status: Active » Postponed
mikeryan’s picture

mikeryan’s picture

Status: Postponed » Closed (duplicate)