django_custom_user_migration 0.3.0

用例

您目前正在使用已部署项目中Django的 django.contrib.auth.models.User 模型，但想迁移到您自己控制或由第三方提供的模型。

先决条件

• Django 1.8或更高版本

• Python 2.7或Python 3.3+

您必须确保在项目的每个地方（包括第三方库）使用 AUTH_USER_MODEL 和 django.contrib.auth.get_user_model() 而不是 "auth.User" 和 django.contrib.auth.models.User。

用法

以下有很多步骤，但几乎都是复制/粘贴，没有复杂性，您可以在5分钟内完成。假设您将在开发环境中执行所有这些步骤，除了最后一个。

1. 将 django_custom_user_migration 安装到您的项目中

   pip install django_custom_user_migration

2. 将 "django_custom_user_migration" 添加到您的 INSTALLED_APPS。

   您现在有一些用于创建迁移的管理命令，我们稍后会用到。

3. 创建一个与Django的 auth.User 完全相同的自定义用户模型，但位于您自己的项目中的一个应用中。为了使此过程正确运行，您需要为该模型创建一个新的应用 - 从现在起我们将其称为 accounts

   # accounts/models.py
   
   from django_custom_user_migration.models import AbstractUser
   
   class User(AbstractUser):
       pass

   该模型可以命名为您想要的任何名称。请记住将此应用添加到您的 INSTALLED_APPS 中。

   在此阶段不要添加额外的字段，也不要更改 AUTH_USER_MODEL。

   我们在此处避免使用 django.contrib.auth.models.AbstractUser 或来自第三方库的用户模型，因为我们遇到了无法解决的 related_name 冲突问题。稍后，我们将改为从 django.contrib.auth.AbstractUser 继承，如果需要，再继承另一个模型。

4. 创建一个正常的迁移来创建该表的表格

   ./manage.py makemigrations accounts

   此迁移必须为 0001_initial，否则您稍后会出现问题，如 AUTH_USER_MODEL 的文档中所述。

   此迁移还将为 AbstractUser 上指定的 M2M 字段创建 M2M 表。

5. 创建一个数据迁移，将从 auth.User 中填充这些表

   ./manage.py create_custom_user_populate_migration auth.User accounts.User

   创建迁移的所有命令都接受类似这样的 <from_model> <to_model> 的参数。

6. 创建一个模式迁移，将更改指向 auth.User 的每个外键，使其指向您的模型

   ./manage.py create_custom_user_schema_migration auth.User accounts.User

7. 创建一个数据迁移，将修复 contenttypes 表的内容

   ./manage.py create_custom_user_contenttypes_migration auth.User accounts.User

8. 将 models.py 中的 AbstractUser 导入更改为

   from django.contrib.auth.models import AbstractUser

9. 将 settings 中的 AUTH_USER_MODEL 更改为 "accounts.User"

10. 再次运行 makemigrations

    ./manage.py makemigrations accounts

    这会创建一个迁移，它实际上不会更改字段，但Django需要它来认为一切又都协调一致。

11. 按照Django文档中描述的进行相关更改：[Django官方文档](https://docs.django.ac.cn/en/dev/topics/auth/customizing/#extending-django-s-default-user)

    最简单的版本

    # accounts/admin.py
    
    from django.contrib import admin
    from django.contrib.auth.admin import UserAdmin
    from . models import User
    
    admin.site.register(User, UserAdmin)

12. 创建一个迁移，该迁移将清空 auth.User 表

    ./manage.py create_custom_user_empty_migration auth.User accounts.User

13. 运行所有迁移

    ./manage.py migrate

14. 测试一切！

    请注意，生成的所有迁移都是可逆的，但在反向运行它们之前，应将 AUTH_USER_MODEL 设置回 "auth.User"，您还需要使用 django_custom_user_migration.models.AbstractModel 作为基类，否则您将遇到阻止迁移运行的验证错误。

    在运行Django单元测试时，当Django尝试在测试数据库中运行迁移时可能会出现问题。由于您的 AUTH_USER_MODEL 已不再指向 auth.User，因此该表将不会创建，并且期望它存在的迁移将失败。

    短期内，您可以按照以下建议进行修复：[Stack Overflow](http://stackoverflow.com/a/28560805/182604)

    长期来看，可以通过将 accounts 迁移压缩到步骤 12 作为一个单一的迁移来修复。使用 squashmigrations 命令执行此操作，然后手动编辑它以删除除初始 CreateModel 操作之外的所有操作。因此，创建的迁移应与 accounts 0001_initial 相同，但它将具有 replaces 属性，将其标记为压缩其他迁移。您可能还需要调整（删除）其依赖项。

15. 卸载 django_custom_user_migration，并从 INSTALLED_APPS 中删除它，您不再需要它。生成的迁移在未安装的情况下也可以运行。

16. 现在您可以将这些迁移部署到生产环境，并按常规方式使用 ./manage.py migrate 运行。

您现在可以按常规方式自定义 User 模型，使用迁移等。您甚至可以使其从 AbstractBaseUser 或其他模型继承，前提是您编写/生成必要的迁移数据以处理缺失的字段，并相应地更新您的管理和应用程序。

其他说明

• 自行承担风险，请先备份您的数据等。

• 已在 sqlite 和 postgres 上进行测试

• 如果您有其他包含对 auth.User 的外键（FK）的表，而 Django 不了解这些表，您将不得不手动使用自定义迁移来处理这些问题。 (在非常旧的 Django 项目中，您可能还有像 'auth_message' 这样的旧表，您需要将其删除。)

• 这个库中包含的大部分内容都是关于涉及模型的通用内容，并且使用反射而不是硬编码关于 auth.User 的内容。唯一的例外是 django_custom_user_migration.models.AbstractUser，它是从 Django 源代码中复制粘贴的。

  这意味着您可能可以使用这里的代码来迁移其他可替换的模型。但是，这尚未经过测试。

历史

0.3.0 (2016-04-04)

• 修复了 Django 1.9 上的崩溃问题

0.2.0 (2015-08-20)

• 修复了 Postgres 中的一个错误，该错误导致序列设置不正确，从而造成后续插入失败。

• 扩展了测试，以实际测试 Postgres

0.1.0 (2015-08-14)

• PyPI 上的第一个版本