Problem/Motivation

SourcePluginBase is an opinionated base source plugin, which helps a lot to create new migrate source plugins.
Splitting it a bit may help to better identify its intention, e.g it may help in contexts like #2809433: Migrate support for deleting items no longer in the incoming data.

Proposed resolution

Split of the iterator related code into a trait.
It would be even better to create an interface for it, but some related methods visibility is protected, which on the interface will be naturally public, and therefore it will be a BC break.

Remaining tasks

Add code change.
Review.

User interface changes

None.

API changes

New trait available.

Data model changes

None.

Release notes snippet

N.A.

CommentFileSizeAuthor
#4 interdiff-2-4.txt617 bytesmarvil07
#4 3048413-4.patch3.53 KBmarvil07
#2 3048413-2.patch3.25 KBmarvil07

Comments

marvil07 created an issue. See original summary.

marvil07’s picture

Assigned: marvil07 » Unassigned
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new3.25 KB

Status: Needs review » Needs work

The last submitted patch, 2: 3048413-2.patch, failed testing. View results

marvil07’s picture

Status: Needs work » Needs review
StatusFileSize
new3.53 KB
new617 bytes
heddn’s picture

Can you provide some rational for why this is necessary? Who will use the trait? We briefly discussed in the migrate maintainers meeting today and couldn't wrap our minds around why this trait is needed or who would use it.

heddn’s picture

Status: Needs review » Postponed (maintainer needs more info)
marvil07’s picture

Status: Postponed (maintainer needs more info) » Needs review

@heddn,

The context where I though about this was #2809433: Migrate support for deleting items no longer in the incoming data, where I was trying to dissect SourcePluginBase to better make sense of it.
It is also a way to better understand the functionality that base class provides.

I guess I was thinking in trying to separate parts of it, since most children classes are based on it, and they are relying more on the base class, than on the interfaces. But again, considering most migrate source plugins are children of it, it would make sense do better define it on interfaces/traits, so descendants which do not want to inherit from it, can choose to add some of its functionality.

Maybe a trait is a poor solution, a better way could be to define more interfaces that the base class implements.

mikelutz’s picture

Status: Needs review » Closed (won't fix)
Related issues: +#3067311: [meeting] Migrate Meeting 2019-07-11

Discussed in migration meeting, marking as closed - won't fix per discussion. Transcript will be available at #3067311: [meeting] Migrate Meeting 2019-07-11