In testing out the new D6 DB dump migration script (migrate-dump-d6.sh), I did the following: I created the D6 site as outlined in the instructions then made a single change - I added a "page specific visibility setting" to the "Powered by Drupal" block (admin/build/block/configure/system/0). I then ran the migrate-dump-d6.sh script and expected to see only the Blocks.php and d6.gz files modified.
Instead, the following files were modified:
modified: core/modules/migrate_drupal/src/Tests/Table/Blocks.php
modified: core/modules/migrate_drupal/src/Tests/Table/Filters.php
modified: core/modules/migrate_drupal/src/Tests/Table/History.php
modified: core/modules/migrate_drupal/src/Tests/Table/Permission.php
modified: core/modules/migrate_drupal/src/Tests/Table/System.php
modified: core/modules/migrate_drupal/src/Tests/Table/TermHierarchy.php
modified: core/modules/migrate_drupal/src/Tests/Table/Users.php
modified: core/modules/migrate_drupal/src/Tests/Table/UsersRoles.php
modified: core/modules/migrate_drupal/src/Tests/Table/Variable.php
modified: core/modules/migrate_drupal/src/Tests/Table/VocabularyNodeTypes.php
modified: core/modules/migrate_drupal/src/Tests/d6.gz
Looking at the diffs (attached, except the d6.gz diff), it seems like there were a bunch of additions. Is this correct?
Thanks,
-mike
| Comment | File | Size | Author |
|---|---|---|---|
| #36 | 2416111-36.patch | 521.19 KB | quietone |
| #31 | 2416111_31.patch | 521.87 KB | chx |
| #30 | 2416111-30.patch | 429.68 KB | quietone |
| #27 | 2416111-27.patch | 429.16 KB | quietone |
Comments
Comment #1
ultimikeSome additional testing...
I just dropped the D6 DB, reimported and then immediately ran the migrate-dump-d6.sh script. There were still changes, but as far as I can tell, they are just rearrangements of the table exports. I've attached the diff.
-mike
Comment #2
ultimikeNext, I made the same "page specific visibility setting" change I made in the original issue above, and this changed two additional table dump files: the blocks.php file (which is the one I expected to be modified) and the variables.php file. The latter was the addition of two default values related to the "Powered by Drupal" block.
So, other than rearrangements, I think it is working. Should I include the rearranged tables as part of any patches moving forward? Seems like that could be a lot of whack-a-mole.
-mike
Comment #3
ultimikeAfter chatting with Benjy about this, I went ahead and added "order by" clauses on three tables to help stem the issues of rearranging. Patch attached.
I'm now wondering if this is going to start happening with other tables and if we should just use an "order by" on all tables?
-mike
Comment #4
benjy commentedWe need to update migrate-dump-d6.sh to add an order by primary key to the exported data. I think we should be able to calculate the primary keys automatically from the schema data we already have.
After we've committed the updated table files everyone will have the same results while exporting the Table's in the future.
Comment #5
benjy commentedComment #6
quietone commentedI've been working on this, enjoying it too, and am about half way done. I hope it is OK that I've assigned it to myself.
Comment #7
benjy commented@quietone, what's your approach? I was hoping to calculate the primary keys automatically based on the available schema data?
Comment #8
quietone commented@benjy, I was working off your suggestion in #4 and used this to get the primary keys.
Comment #9
benjy commentedThat seams reasonable, the only thing I did think was that the data may already exist in $row ?:
Comment #10
quietone commentedYes, but I don't see how that helps. Using 'key' from a row as you suggest would mean that the code would have to do extra sorting. Why not let the db do that? Or, I'm just plain missing something?
Note that my patch only changes the $values output, which is where the differences are in d6_dump_no_changes.diff. I presume $fields should be as well?
Comment #11
benjy commentedTook another look, I see what you mean. Yes, I like this approach.
Did we have a patch with the newly generated dumps? Hopefully it's not too much of a radical change.
Comment #12
quietone commentedYes, here it is. 12 dump files changed.
I'm getting AJAX errors when trying to run the tests, so I'll see what the testbot finds while I investigate.
Comment #20
quietone commentedRight, increased the PHP memory limit and tests pass locally. Is the testbot sick today?
Honestly, suggestions?
Comment #21
benjy commentedYes, I think testbot is just having issues.
Comment #22
quietone commentedtest again
Comment #25
quietone commentedTry again
Comment #27
quietone commentedAnd again
Comment #28
quietone commentedComment #29
ultimike@quietone - I just tried downloading and applying the patch and I couldn't - but only because of the binary d6.gz file embedded in the patch.
Would you mind re-rolling using
git diff --full-index --binary > 2416111-x.patch?Regardless, I think the patch looks good, but I think core committers will have a hard time applying it as-is.
Looking forward to this patch getting in, as it will save all of us some time when we have to add new tests!
Thanks,
-mike
Comment #30
quietone commentedSure. Here it is.
Comment #31
chx commentedSorry that's still not a binary dump :/ but this is :) Otherwise no change.
To roll this, you need
core/modules/migrate_drupal/src/Tests/.gitattributesto contain*.gz -diff.Comment #32
quietone commented@chx, thanks. As they say, you learn something new every day. But I think you meant
*.gz -binary?Comment #33
ultimikeIt should look like
d6.gz -text -diff@quietone - is your local D8 at HEAD? This has already been committed, see core/modules/migrate_drupal/src/Tests/.gitattributes
-mike
Comment #34
quietone commentedYes, I work from HEAD.
core/modules/migrate_drupal/src/Tests/.gitattributes does not exist, nor do I see one on GitHub.
Yes,
*.gz -text -diffworks withgit diff --full-index --binary. Seems like I'm a lazy typist and was using "git diff" and thus needed different .gitattributes file to get a patch that matched chx's.Comment #35
alexpottNeeds a reroll
Comment #36
quietone commentedDone
Comment #37
chx commentedLet's try again.
Comment #38
alexpottMigrate is not frozen in beta. Committed e975bb1 and pushed to 8.0.x. Thanks!
Comment #41
quietone commented