Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Data is needed for testing the various i18n migrations, strings, blocks, taxonomy etc. It will be easier to add it in all one patch.
Historically, the dump files have been updated as part of the patch for each single migration. That certainly allows the developer to really understand the data source but it adds extra work to each patch. That extra work can be avoided if the data is already in the dump file. And hopefully, it will make it easier to work on the migrations.
Remaining tasks
Do it.
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Comments
Comment #2
quietone CreditAttribution: quietone as a volunteer commentedComment #5
Gábor HojtsyI think patches like #2225717: Add config translation support to migrations and implement for Drupal 6 user profile fields are adding the individual data to test, which IMHO is fine to go forward still, so closing this in favor of doing it the "old way" and adding the test data with the test so we can prove it works.
Comment #6
Gábor HojtsyErm, it is more like #2225293: Migrate D6 and D7 language negotiation settings is an example, not the prior ones.
Comment #7
quietone CreditAttribution: quietone as a volunteer commentedI think making small isolated changes to a dump increases the introduction of errors. One example is Same nid in two content types in d6_dump. And, I believe that having to modify a db dump discourages people from working on migration issues. At least, I don't recall any of the migrate contributors being eager to modify the dumps. And for myself, I'll just say that it would be better to make it easier to work on migration issues that need a working db dump.
Since this issue is about adding i18n data to d7_dump, we can use the knowledge gained from adding the d6 i18n data. I'd like to hear other opinions so setting back to Active.
Comment #8
Gábor HojtsyWell, we are already adding that data in other issues, no? Also when you need to figure out what to do to the source data, how does the source data look like to migrate, that is useful for the migration code itself, so doing it in one issue is more helpful for retaining that knowledge. If we figure out the source data here and then again in individual issues when we actually do the migration, that we need to do that discovery twice, no?
Comment #10
quietone CreditAttribution: quietone as a volunteer commentedI'll have a look to see what needs to be done here.
Comment #11
quietone CreditAttribution: quietone as a volunteer commentedI am not proposing we figure out the data here, just create it. We know that we need translation strings for every existing migration, that we need to migrate block, field and menu and node translations, etc. Let's just create it. The figuring out and understanding the data is done in the development of the migration, not in creating the data.
I also think it is risky to be building our test database fixtures piece by piece in a variety of issues. How will we prevent conflicts? Will we always be able to bring up a functioning site using the test fixture?
Also, multiple issues modifying the db dumps is more than likely going to cause rerolls, as it has in the past.
Comment #12
Gábor HojtsyDo we not have most of this data already at this point thanks to the smaller issues?
Comment #13
quietone CreditAttribution: quietone as a volunteer commentedI think the only translation work on D7 is the core node translation. There aren't any issues yet for D7 i18n.
Comment #14
heddnComment #15
maxocub CreditAttribution: maxocub commentedHaving wrote migrate patches with existing data in the dump and without, I think I agree with @Gábor Hojtsy.
I find that when the data was already present in the dump, it was rarely exactly what I needed for my tests, and it's sometimes was just plain wrong. Modifying it made me nervous about breaking other tests.
On the other hand, when the data wasn't there, it forced me to understand how the data I was trying to migrate was stored in D6 or D7.
Both ways, modifying the dump was required, so I think that trying to foresee exactly what data we will need for tests is not that useful.
Comment #16
heddnDoes someone have the nerve to close this as "won't fix"?
Comment #17
maxocub CreditAttribution: maxocub commentedFeel free to reopen if you think this should be done.