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
When restoring the migrate test dump you have a broken site without an anonymous or uid 1 user.
Proposed resolution
Add them to the dumps.
Remaining tasks
Review/commit.
Comment | File | Size | Author |
---|---|---|---|
#15 | 2562695-15.patch | 4.51 KB | phenaproxima |
#12 | 2562695-12.patch | 4.81 KB | phenaproxima |
#10 | 2562695-10.patch | 3.3 KB | phenaproxima |
#2 | all-users-in-migrate-dump.patch | 6.64 KB | neclimdul |
all-users-in-migrate-dump.patch | 6.64 KB | neclimdul | |
|
Comments
Comment #2
neclimdulpatch, lets see what testbot thinks.
Comment #3
phenaproximaLooks good to me, but can this also include updated dumps for D7?
Comment #5
benjy CreditAttribution: benjy at PreviousNext commentedWe did this on purpose because we didn't want uid 0 and 1 in the dumps since they're automatically created when you install your D8 site. ID's *should* be preserved because things like user ids are often important. Take for example a drupal.org upgrade, I don't think everyone would like getting a new user id.
If we had another way around ignore user 0/1 then we could do this but from what i'm aware, it only affects people altering the dumps.
Comment #6
phenaproximaYes, uid 0 and 1 are created when you install a D6/7 site, but that sidesteps the purpose of migrate-db.sh, which is to dump or restore a completely functional D6 or D7. Drupal never installed -- not by people who use migrate-db.sh to create fixtures, and not by the tests.
Comment #7
mikeryanMore context in the related issue...
Comment #8
benjy CreditAttribution: benjy at PreviousNext commentedDiscussed on IRC, I think the ids were removed to get around an issue which i think the current patch shows and I think the issue Mike linked shows how to fix that.
Comment #9
neclimdulThe actually problem causing the failures with the current patch is mysql treating 0 as "use autoincrement". SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO" is the fix but its database specific so this is hairy. mike linked #204411: Anonymous user id breaks on MySQL export/import (xID of Zero get's auto-incremented on external xSQL events) in IRC which discusses this. Since auto increment starts at 1, the first insert creates uid 1. then the insert with uid 1 fails.
As noted in the discussion on the other issue, not dumping uid 1 is actually just a weirdness. we skip it anyways in migrations so we're just making things weird for people manual testing and using the migrate script to build patches.
Comment #10
phenaproximaTry again...
Comment #12
phenaproximaI, like, can't even.
Comment #13
neclimdulThat explains why your patch sizes are odd.
Comment #14
mikeryanOoh, let's save that for #2560637: Improve handling of uid 1 during migration. If we commit this then D6 upgrades will unconditionally overwrite the admin account.
Comment #15
phenaproximaGood call! Fixed.
Comment #17
mikeryanlgtm
Comment #19
neclimdul+1 RTBC
Comment #20
phenaproximaThis is blocking a Migrate critical: #2560637: Improve handling of uid 1 during migration.
Comment #22
benjy CreditAttribution: benjy at PreviousNext commented+1 from me.
Comment #23
webchick1000 yays for this patch, tho I'm confused about this hunk in core/modules/user/src/Tests/Migrate/d6/MigrateUserTest.php:
Why do we deliberately add UID 1 info to the dump, but then deliberately skip testing it in the tests?
Comment #24
mikeryanThe actual source plugin is skipping uid 1, so the test needs to skip it for now. As for why we have not changed the source plugin to now handle uid 1, there's more to that than just putting it through the pipeline as if it were a normal account, which we will deal with in #2560637: Improve handling of uid 1 during migration,
Comment #25
phenaproximaWhat he said! Restoring RTBC.
Comment #26
webchickAwesome, thanks for the response. See you over in #2560637: Improve handling of uid 1 during migration then!
Committed and pushed to 8.0.x. Thanks!