Hello all, it’s time for the biweekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every second Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.
| benjifisher |
#2713327: Document ways to remove migration tables (ID map etc.) |
| mikelutz (he/him) |
I suppose we can at least run tests on the latest patch. |
| benjifisher |
quietone (#156) reminded me that I promised (#144, not #44) to do some wordsmithing:
For example, replace "This is a process that is not reversible" with "This action cannot be undone", which is used pretty consistently in Drupal.
|
| benjifisher |
Is that the only thing holding up this issue? |
| smustgrave |
I haven’t reviewed it as quietone seemed to specifically want you or assuming another submaintainer to review. (edited) |
| smustgrave |
Seemed pretty advanced for someone like me to make the call that it was the correct approach |
| mikelutz (he/him) |
I bumped it back to NW with some complaints about the approach. |
| mikelutz (he/him) |
I don’t want to add a UX to the api module. |
| mikelutz (he/him) |
the api should provide apis, and it does provide an api to remove tables through MigrateIdMapInterface::destroy() |
| mikelutz (he/him) |
It should be up to the drush commands and UX modules like migrate tools and migrate_drupal_ui to provide a UX for that api. |
| benjifisher |
I think we are planning to add UI to the API module in #3063856: Add ability to view migrate_message table data |
| benjifisher |
But this issue is much more likely to be needed for sites that have used migrate_drupal, so I think there is an argument for putting the changes in migrate_drupal_ui. |
| mikelutz (he/him) |
YEah.. Now that you mention it, I’m not a fan of that being in the api module either. |
| benjifisher |
Unfortunately, we do not have a separate migrate_ui module (and we will not add one at this point). |
| mikelutz (he/him) |
That should also go in migrate tools. |
| mikelutz (he/him) |
No, we won’t. I think of migrate tools as the migrate_ui module, but I admit its messy. |
| benjifisher |
But migrate_tools is designed to work with config migrations, based on migrate_plus. I think it already exposes migration messages from those. |
| mikelutz (he/him) |
I won’t stand in the way of adding table deletion UI in the api module, but I’m not a fan. |
| mikelutz (he/him) |
Yes, I would prefer a migrate_ui module in core, and no, that’s not happening. |
| mikelutz (he/him) |
but I feel like we are opening a can of worms with these. |
| mikelutz (he/him) |
The migrate module should be a developers api, and shouldn’t provide UX. It should provide tools geared towards developers. |
| benjifisher |
Yes, but then there should be a migrate_ui module. As long as we are wishing for things that will not happen, I would like to make migrate_plus an API module (process plugins, the uri source plugin, and the fetcher and parser plugins related to that) and move the config migrations to migrate_tools, which also provides UI for them. (edited) |
Comments
Comment #6
benjifisherComment #7
smustgrave commentedWent into slack and #migration channel to 9/28/2023 and all the conversations threads have been captured.