#25313: Document how to migrate from a built-in User model to a custom User
model
-------------------------------+------------------------------------
Reporter: carljm | Owner: nobody
Type: New feature | Status: new
Component: Documentation | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by aaugustin):
Replying to [comment:5 carljm]:
> Hmm. Clearly it must be partially possible, otherwise you could never do
this at all if you use any third-party apps that link to `User` (since you
won't be changing their migration files).
Indeed you don't change the migration files. But you drop
`django_migrations`, change `settings.AUTH_USER_MODEL` and repopulate
`django_migrations`. While some migrations have the same name in
`django_migrations`, you don't have the same set of migrations and their
semantic has changed. Specifically:
- you add at least the migration that creates your custom user model
- the `auth.000_initial` migration has a different semantic because it
doesn't create a table for `auth.User`
> The whole reason we special-case swappable models in migrations (instead
of just treating them concretely) is to allow for migrations to not be
dependent on the value of `AUTH_USER_MODEL`, so that reusable apps
depending on `User` can still generate workable migrations.
That's the trick. A migration file that contains a migration that uses the
`swappable` option isn't a self-contained definition. Only the combination
of the migration file and the value of `getattr(django.conf.settings,
swappable)` is. This isn't reflected in the structure of
`django_migrations` because Django currently assumes `AUTH_USER_MODEL` to
be immutable.
> It's true that changing `AUTH_USER_MODEL` changes the _meaning_ of
historical migrations in some sense, but it still seems to me that if our
approach for reusable apps actually works, the same migration files ought
to be salvageable (presuming that when you switch `AUTH_USER_MODEL` you
point it to a new model that is initially exactly the same as the previous
one, and then only modify it in later, separate migrations).
I remember feeling smart, then making a huge mess of a SQLite database,
feeling dumb, editing the dump manually to fix broken FK constaints,
feeling lucky.
> But you've actually done this and I haven't, so I'm probably wrong...
Well, perhaps there's a way.
Even then I'd recommend the procedure I suggested above because:
- it's reasonably convenient: people have a fair chance to execute it
successfully
- it makes it clear that you're voiding your warranty (not that Django
comes with a warranty, but you get the point)
- it's possible to reason about why it works
--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.06f09e41ebc19566bbb0b79e02794427%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
