Core migration issues
Next video meeting 2025-01-02 (tentative)
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. #3456078: [meeting] Migrate Meeting 2024-07-18 2100Z)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 👤 emoji. To take a comment or thread off the record, start with a 🚫 emoji.
0️⃣ Who is here today?
| alison | Alison here, just lurking |
| mikelutz (he/him) | Hi all, sorry I’m late getting this started. |
| Dan Davis | Hello! |
| benjifisher | Hi! I am trying to multi-task. :disappointed: |
| dinarcon | :wave: |
| quietone | Hi |
1️⃣ What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today's meeting.
| benjifisher | https://www.drupal.org/project/drupal/issues/2845340 |
| benjifisher | https://www.drupal.org/project/drupal/issues/3421014 |
2️⃣ Action items. To be added later.
3️⃣ Statistics
| Migrate Initiative Meeting | 1 Fixed, 1 RTBC, 3 NR, 352 Open issues. |
| Migrate Initiative Meeting | Google sheet for recording stats: https://docs.google.com/spreadsheets/d/1o0Rjlc1vnnLP5bM5P-SMMyGzqn7258hi... |
4️⃣ Comment in this thread if you are looking for ways to contribute. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...
5️⃣ Previous minutes.
| Migrate Initiative Meeting | https://www.drupal.org/project/drupal/issues/3477036 (edited) |
6️⃣ Announcements
| dinarcon | DrupalCon Barcelona 2024 session recordings are available https://m.youtube.com/playlist?list=PLpeDXSh4nHjQOfQV-BUgoxHXlr4tHlhPO there are some migration related |
| benjifisher | @dinarcon: What is your latest in the new D7 -> D8+ migration series? |
| dinarcon | The last article wraps up migrating configuration. The next one talks about avoiding entity ID conflicts, and then content migrations https://www.tag1consulting.com/services/d7-d10-data-migration-guide |
7️⃣ migrate mapping & messages table names are truncated, can lead to incorrect mapping lookups
| Migrate Initiative Meeting | By benji |
| Migrate Initiative Meeting | (Original Request) https://drupal.slack.com/archives/C226VLXBP/p1731015128347969?thread_ts=... (edited) |
| benjifisher | I see this issue is back to NR. Some versions of the patch/MR have involved changing the name of tables in the database. That approach scares me, so I want to see what the current approach is. |
| benjifisher | /** * Rename migrate tables for existing migrations to avoid naming conflicts. */ function migrate_update_10101(&$sandbox): void { \Drupal::classResolver(MigrateUpdateHelper::class)->updateTableNames(); } |
| benjifisher | That ^ is from the current MR. So I guess the approach has not changed. |
| quietone | There is still the problem of resolving when two migrations result in the same table name. Comment #47 |
| benjifisher | What could be more disruptive than changing the name of a database table? If something goes wrong, is there any way to recover? |
| quietone | Yes, the backup the site made before running the update. |
| benjifisher | What if someone has a script that runs SQL queries that hard-code the table name. How long will it be before they notice that their script is broken? How will they recover? |
| benjifisher | @quietone: That works if you notice the problem right away. In my experience, a lot of problems are undetected until they start causing problems. At that point, it is too late. |
| benjifisher | @mikelutz (he/him): Do you ever modify your map tables with SQL queries instead of using API functions? |
| quietone | We can inform sites via a CR and in the release notes. |
| quietone | We could maybe even be helpful and dump a log of the old and new table names. |
| benjifisher | I am more pessimistic than you are. I think that xjm is of the opinion that the only people who read release notes are release managers (and those with the aptitude to become release managers). |
| benjifisher | IMO we should create new map/message tables using the new method, but we should support existing tables indefinitely. |
| benjifisher | Migration is for arbitrary data import, not just site upgrades. |
| benjifisher | Nice to have: an optional way to convert tables from old names to new names. That can be a follow-up issue. The first order of business is to stop creating new tables with ambiguous names. |
| quietone | Thinking |
| quietone | We should ask the Database API maintainer for their opinion. |
| benjifisher | @daffie: Good, I see you are in this channel! :wink:The issue at the top of this thread proposes to clone some database tables in an update function. The updated code would use the new table.More or less: rename the table, making a backup.What do you think of that idea? If we go ahead with it, what precautions should we take? What problems should we anticipate? |
| daffie | @benjifisher I did a review from the database maintainer perspective. For the update function. Make a backup for the whole database before you start the update and during the update process just rename the tables. The copying of data will take a long time when you have a big migration and a cheap/shared hosting. |
7️⃣ Convert MigrateSource plugin discovery to attributes
| Migrate Initiative Meeting | . |
| Migrate Initiative Meeting | (Original Request) https://drupal.slack.com/archives/C226VLXBP/p1731015166784829?thread_ts=... (edited) |
| benjifisher | This is still on my list, even though I have not had a chance to look at it since the last meeting. |
| benjifisher | @quietone: Last week, you wrote,I am sure we have an existing agreement to not move all the source plugins to migrate_drupal. I recall the plan is to rely on deprecating DrupalSqlBase.and linked to[#3315257] |
| benjifisher | The "Remaining tasks" section starts withMove integrations implemented by other modules to the extension.The first bullet points under that isMove integrations implemented by other modules to the extension.I do not read that as explicitly deciding for or against moving source plugins to migrate_drupal. |
| benjifisher | Did we decide not to move them just because it is a lot of extra work or because we anticipated problems? If it makes a difference for this issue (converting to attributes) then maybe we are allowed to change our minds. |
| benjifisher | I have not yet figured out how the two are related. Sorry. |
| benjifisher | I did not read the comments, but the summary of the plan issue does not say anything for or against moving source plugins to migrate_drupal. |
| quietone | I guess another solution is to move all d6/d7 source plugins to migrate_drupal , with the existing classes extending the new migrate_drupal classes.I was responding to this idea, expressed by @godotislate at https://drupal.slack.com/archives/C226VLXBP/p1729782896462309?thread_ts=... |
🔟 Wrap-Up
| Migrate Initiative Meeting | Thanks for coming all! See you in 2 weeks |
Participants:
benjifisher, Migrate Initiative Meeting, dinarcon, quietone, daffie
Comments
Comment #2
smustgrave commentedComment #3
ddavisboxleitner commentedComment #7
smustgrave commentedAdding credit and verified threads
Comment #8
smustgrave commentedForgot to save for ddavisboxleitner and benjifisher