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

benjifisher created an issue. See original summary.

smustgrave’s picture

Status: Active » Needs work
ddavisboxleitner’s picture

Issue summary: View changes

smustgrave credited daffie.

smustgrave’s picture

Status: Needs work » Fixed

Adding credit and verified threads

smustgrave’s picture

Forgot to save for ddavisboxleitner and benjifisher

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.