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 | Welcome! |
| mikelutz (he/him) | Morning all. |
| Stephanie | Late to the party |
| Dan Davis | Hello |
| alison | Hi! - Lurking at least! |
| quietone | Late, as per usual lately |
| Migrate Initiative Meeting | All open: 353.
Fixed in the last 2 weeks: 2 (not counting issues for meetings). RTBC: 5, 1 of which is Major. NR: 0. Needs subsystem maintainer review: 8 |
| Migrate Initiative Meeting | Google sheet for recording stats: https://docs.google.com/spreadsheets/d/1o0Rjlc1vnnLP5bM5P-SMMyGzqn7258hi... |
| Migrate Initiative Meeting | #3417346: [meeting] Migrate Meeting 2024-02-01 2100Z (edited) |
| benjifisher | We have not yet added a transcript to that issue. |
| Dan Davis | I can work on that |
| Dan Davis | @benjifisher I updated the description with a first pass of copying in the meeting posts. This time it seems the links all just worked? Can you please give it a review when you get a moment? |
| benjifisher | #3247718: Allow process plugins to flag a row to be skipped |
| benjifisher | @mikelutz (he/him), any progress? |
| mikelutz (he/him) | Haven't had a chance to pick it back up yet, is still on my list. |
| benjifisher | There is a recent comment from Ghost of Drupal Past (not on Slack?) that throwing an exception is the appropriate way to manage control flow. |
| benjifisher | This thread is related to 8️⃣. If we close this issue as "won't fix", then that removes a big reason for deprecating no_stub in the destination configuration. |
| mikelutz (he/him) | I’m like 98% sure that account is an alt of chx, who introduced MigrateSkipRowException in #2160345: Clean up and test migrate executable and sql idmap#comment-8350139…. I still intend to push this forward, and if we don’t want to deprecate no_stub in destination configuration, we can still implement it in this new system, we just need to check for it earlier and skip the row in the lookup. |
| benjifisher | #3404022: Remove unused no stub from block content migration files |
| benjifisher | Randomly chosen from the list of "needs subsystem maintainer review". |
| benjifisher | @mikelutz (he/him): You wrote,
|
| benjifisher | I guess that happens in Migration::getDestinationPlugin(). |
| benjifisher |
|
| benjifisher | The migration_lookup plugin has an option to select which migration to use for stubs. So this is feasible. |
| benjifisher | I guess it is a question of developer experience (DX). Say I am using migration_lookup, perhaps looking up in a list of migrations. Almost always, the migrations will be similar, so they will all use the same destination plugin. |
| benjifisher | Currently, some of the migrations I use for the lookup can say that they are not suitable for creating stubs. Presumably, something will go wrong if they try. |
| benjifisher | Not knowing every detail of the migration system, I write my migration and try to use an inappropriate plugin for the lookup. As it is now, I get a MigrateSkipRowException with the message
If we deprecate and then remove that option, then I will get some other error later on in the process. |
| benjifisher | Generally, catching the problem early is a good idea, and the error message is more actionable. |
| benjifisher | @Dan Davis, @Stephanie: Do either of you have practical experience with using migration_lookup and deciding which (if any) migration to use for stubbing? |
| Dan Davis | I do not, sorry. |
| Stephanie | I almost always specify no_stub in my migration_lookup code because it seems like it causes more trouble than it is worth. I haven't ever set no_stub on a destination plugin. |
| benjifisher | Same here. |
| benjifisher | @mikelutz (he/him): I commented on the issue. I think we should add a test (as you say) and also some documentation, and move the discussion to other issues. If you agree, then we can update the remaining tasks and remove the NSMR tag. (edited) |
| mikelutz (he/him) | On the wish list for a new migration_lookup plugin is to change the default such that stubbing is opt-in rather than opt-out, so that would help. Otherwise, if we do want to keep the ability for migrations to declare themselves unstubbable, I’m not fully opposed, but we should refactor the system a bit, detect it in the stub service, maybe throw a different exception. Since it’s technically an invalid migration configuration, we should probably fail the whole migration with a more clear message and handle the situation directly in the stub service and migration_lookup plugins. |
| amaisano | and maybe consider top-down migrations in these changes, too? |
| amaisano | those are heavily dependent on the stubbing system, as you know (you helped us out a couple months ago) |
| benjifisher | Thanks for participating! I will update 2️⃣. Please continue to add comments in the threads. In 1-7 days, we will post a transcript for today's meeting. |
Comments
Comment #6
benjifisherComment #7
smustgrave commentedWent into #migration in slack for 2/15/2024 and all threads were captured and all users who participated in the threads credited.