[Django] #25313: Document how to migrate from a built-in User model to a custom User model

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
#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:  Migrations   |        Version:  1.8
               Severity:  Normal       |       Keywords:
           Triage Stage:  Unreviewed   |      Has patch:  0
    Needs documentation:  0            |    Needs tests:  0
Patch needs improvement:  0            |  Easy pickings:  0
                  UI/UX:  0            |
---------------------------------------+------------------------
 (I'd have thought we might already have a ticket for this, but I couldn't
 find it.)

 So far our answer here has been "sorry, you can't do it, unless you're
 very familiar with the depths of the migrations system and willing to put
 a lot of time into it."

 I don't believe that this is a tenable or defensible answer. It puts too
 many of our users, too frequently, into an impossible quandary. I think we
 need to clearly document how you can do it today, even if the process is
 nasty and ugly. Hopefully seeing that nasty and ugly documentation might
 clarify what could be improved to make the process less nasty and ugly.

--
Ticket URL: <https://code.djangoproject.com/ticket/25313>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/049.bd4aeab7050bc00e540295a23a9a888a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
#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
-------------------------------+------------------------------------
Changes (by timgraham):

 * component:  Migrations => Documentation
 * stage:  Unreviewed => Accepted


Old description:

> (I'd have thought we might already have a ticket for this, but I couldn't
> find it.)
>
> So far our answer here has been "sorry, you can't do it, unless you're
> very familiar with the depths of the migrations system and willing to put
> a lot of time into it."
>
> I don't believe that this is a tenable or defensible answer. It puts too
> many of our users, too frequently, into an impossible quandary. I think
> we need to clearly document how you can do it today, even if the process
> is nasty and ugly. Hopefully seeing that nasty and ugly documentation
> might clarify what could be improved to make the process less nasty and
> ugly.

New description:

 So far our answer here has been "sorry, you can't do it, unless you're
 very familiar with the depths of the migrations system and willing to put
 a lot of time into it."

 I don't believe that this is a tenable or defensible answer. It puts too
 many of our users, too frequently, into an impossible quandary. I think we
 need to clearly document how you can do it today, even if the process is
 nasty and ugly. Hopefully seeing that nasty and ugly documentation might
 clarify what could be improved to make the process less nasty and ugly.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:1>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.a62274dbcadec0f89745f3a200727a50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#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):

 I did it at least twice. Unfortunately I don't remember all the details.

 I think a reasonable procedure is:

 1. Create a custom user model identical to `auth.User`, call it `User` (so
 many-to-many tables keep the same name) and set `db_table='auth_user'` (so
 it uses the same table)
 2. Throw away all your migrations
 3. Recreate a fresh set of migrations
 4. Sacrifice a chicken, perhaps two if you're anxious; also make a backup
 of your database
 5. Truncate the `django_migrations` table
 6. Fake-apply the new set of migrations
 7. Unset `db_table`, make other changes to the custom model, generate
 migrations, apply them

 It is highly recommended to do this on a database that enforces foreign
 key constraints. Don't try this on SQLite on your laptop and expect it to
 work on Postgres on the servers!

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:2>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.e11b56d5e7781a8643edca9dd6bdcff4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#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 carljm):

 Hmm. I thought I recalled you mentioning (at DUTH last year?) that you
 achieved it using `SeparateDatabaseAndState`, without the need to wipe
 migrations and start over. Maybe that was someone else.

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:3>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.d80fd6e674805ee043678ad4e6c921d0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#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):

 At some point I thought it was doable with `SeparateDatabaseAndState` but
 eventually I realized that it isn't.

 When you change `settings.AUTH_USER_MODEL`, suddenly Django has a
 different view of the migration history. Piling hacks cannot hide this
 fact. I don't think it's possible to salvage migration history when
 changing `AUTH_USER_MODEL`.

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:4>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.27e4b2eba10b6d0c8670635732a53dd4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#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 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). 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.

 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).

 But you've actually done this and I haven't, so I'm probably wrong...

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:5>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.5c214ae8b8b1fbc7006965cdf9bcef07%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#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 shaib):

 <brainstorming idea="halfbaked">

 Perhaps it is possible to create a migration operation for changing a
 swappable model.

 Something like:
 {{{
 ChangeSwappableModel(
     setting="AUTH_USER_MODEL",
     old="auth.User",
     new="my_auth.User"
 )
 }}}

 This would be a migration in the `my_auth` app.

 It would need to introspect the database, checking the constraints
 corresponding to `my_auth.User`'s reverse relationships, and verifying
 that they indeed point to the correct table (if they point to `auth_user`,
 change them;  if to `my_auth_user`, leave them be; otherwise, error out).

 To change the swappable model, one would:
 1) Create the set of migrations for creating the new user model, porting
 existing data to it, and  the `ChangeSwappableModel` operation;
 2) Create a "squashing" migration replacing them by just creating the new
 model, so new databases don't have to suffer

 I think with careful migrations embargos in the right times this could be
 made to work. I don't have it in me to work out all the details now, and
 I'm probably missing something essential.

 </brainstorming>

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:7>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.80046d3991c79346323ff2fed5d21028%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#25313: Document how to migrate from a built-in User model to a custom User model
-------------------------------+------------------------------------
     Reporter:  Carl Meyer     |                    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 James Addison):

 I think I've followed a very similar process in previous projects (older
 Django versions) to what Aymeric mentions above in
 https://code.djangoproject.com/ticket/25313#comment:2 - although I don't
 think you can ever 'unset' `db_table` without having to do low level SQL
 changes?

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:8>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.776eb3fe8b7329f710f98a33cd218678%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#25313: Document how to migrate from a built-in User model to a custom User model
-------------------------------+------------------------------------
     Reporter:  Carl Meyer     |                    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 Justin Smith):

 Replying to [comment:2 Aymeric Augustin]:
 > I did it at least twice. Unfortunately I don't remember all the details.
 >
 > I think a reasonable procedure is:
 >
 > 1. Create a custom user model identical to `auth.User`, call it `User`
 (so many-to-many tables keep the same name) and set `db_table='auth_user'`
 (so it uses the same table)
 > 2. Throw away all your migrations
 > 3. Recreate a fresh set of migrations
 > 4. Sacrifice a chicken, perhaps two if you're anxious; also make a
 backup of your database
 > 5. Truncate the `django_migrations` table
 > 6. Fake-apply the new set of migrations
 > 7. Unset `db_table`, make other changes to the custom model, generate
 migrations, apply them
 >
 > It is highly recommended to do this on a database that enforces foreign
 key constraints. Don't try this on SQLite on your laptop and expect it to
 work on Postgres on the servers!

 Just recently had to go through this process using a Microsoft SQL Server
 backend and used the steps above as my guideline. Just thought I'd drop in
 and include some of my notes just in case they can help anyone in the
 future.

 Notes (by step):
 1. Make sure the custom user model identical to auth.User is an
 `AbstractUser` model. I originally made this mistake because I did an
 `inspectdb auth_user` and just copy/pasted so I left it as `models.Model`
 at first. Since I copied and pasted from `inspectdb` I went ahead and
 removed `managed = False`
 2. Quick shortcut to delete migrations for all apps in a project I used
 was `find . -path "*/migrations/*.py" -not -name "__init__.py" -delete`.
 3. No additional notes
 4. Not kidding about the back up I had to start over a few times
 5. No additional notes
 6. I did `--fake-initial` first few times and not `--fake`
 7. No notes

 Thank you very much for posting this in the first place I am not sure I
 would have figured this out on my own and saved us mid-project. I have
 learned my lesson about starting a django project and not setting up
 custom user model.

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:9>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.7fbca9af17ead0ffe55257f807159338%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#25313: Document how to migrate from a built-in User model to a custom User model
-------------------------------+------------------------------------
     Reporter:  Carl Meyer     |                    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 Luke Plant):

 I created this project which was my attempt to automate the process:

 https://bitbucket.org/spookylukey/django_custom_user_migration

 However, I think Aymeric's solution looks better.

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:10>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.e7c27d5cbb1349dea62823692c3191f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#25313: Document how to migrate from a built-in User model to a custom User model
-------------------------------+------------------------------------
     Reporter:  Carl Meyer     |                    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 Pi Delport):

 These are steps we took to switch our system to a custom
 `AUTH_USER_MODEL`, for the record:

 0. (Take full backups!)
 1. Dump the database with: `django-admin dumpdata --natural-primary
 --natural-foreign --exclude contenttypes.contenttype`
 2. Run the JSON dump through a script that rewrites references from the
 old user model to the new one. (See below.)
 3. Define our new custom user model as a `AbstractUser` subclass, with no
 other schema changes. Update `AUTH_USER_MODEL` to it, nuke all our app's
 old migrations, and make fresh initial migrations.
 4. Create and `django-admin migrate` a fresh new database, and load the
 rewritten dump.

 After this point, we can customise our user model with normal Django
 migrations.

 The script to rewrite the dump iterates through the list of objects, and
 rewrites:

 * The user's' `model` itself.
 * The user's `user_permissions` field's references.
 * The `auth.group` `permissions` field's references.
 * The `auth.permission` and `admin.logentry` `content_type` fields.
 * Any other references to the old `auth.User` type will need rewriting
 too.

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:11>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.b690c51b4dfb0ccbd6cfed3c08853588%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

Django
In reply to this post by Django
#25313: Document how to migrate from a built-in User model to a custom User model
-------------------------------+------------------------------------
     Reporter:  Carl Meyer     |                    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 dustingtorres):

 Replying to [comment:2 Aymeric Augustin]:
 > I did it at least twice. Unfortunately I don't remember all the details.
 >
 > I think a reasonable procedure is:
 >
 > 1. Create a custom user model identical to `auth.User`, call it `User`
 (so many-to-many tables keep the same name) and set `db_table='auth_user'`
 (so it uses the same table)
 > 2. Throw away all your migrations
 > 3. Recreate a fresh set of migrations
 > 4. Sacrifice a chicken, perhaps two if you're anxious; also make a
 backup of your database
 > 5. Truncate the `django_migrations` table
 > 6. Fake-apply the new set of migrations
 > 7. Unset `db_table`, make other changes to the custom model, generate
 migrations, apply them
 >
 > It is highly recommended to do this on a database that enforces foreign
 key constraints. Don't try this on SQLite on your laptop and expect it to
 work on Postgres on the servers!

 Thanks for this, I followed your steps and Justin Smith's notes and want
 to add one more:

 6b. Any model that has a link to ContentType may be linked to the now
 stale auth.User content type. I went through and updated all models that
 were pointing to auth.User content type to my new User model. You can find
 out what type of objects would be removed due to cascading delete of the
 stale auth.User content type by running `manage.py
 remove_stale_contenttypes` **and make sure to answer NO** when asked if
 you want to proceed.

 If you don't unset `db_table` the above step may be optional since the
 content type lookup will use auth.User model which will still have a valid
 database table (although I don't recommend relying on this).

--
Ticket URL: <https://code.djangoproject.com/ticket/25313#comment:12>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/064.a95c150b138cb08d962d8dfcd9e4b989%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.