django的auth_user.username可以是varchar（75）吗？怎么办？ [英] Can django's auth_user.username be varchar(75)? How could that be done?

问题描述

在 auth_user 上运行alter table有什么问题，使用户名成为 varchar （75）所以它可以适合电子邮件？如果有任何事情会破坏什么？

Is there anything wrong with running alter table on auth_user to make username be varchar(75) so it can fit an email? What does that break if anything?

如果要将 auth_user.username 更改为 varchar（75）你需要在哪里修改django？这是否只是在源代码中改变30到75的问题？

If you were to change auth_user.username to be varchar(75) where would you need to modify django? Is it simply a matter of changing 30 to 75 in the source code?

username = models.CharField(_('username'), max_length=30, unique=True, help_text=_("Required. 30 characters or fewer. Letters, numbers and @/./+/-/_ characters"))

或者是否有必要更改此字段的其他验证或其他任何影响？

Or is there other validation on this field that would have to be changed or any other repercussions to doing so?

请参阅下面bartek的评论讨论，了解原因。

See comment discussion with bartek below regarding the reason for doing it.

修改：几个月后回顾一下。对于任何不了解前提的人：某些应用没有使用用户名的要求或愿望，他们只使用电子邮件注册和AUTH。不幸的是，在django auth.contrib中，用户名是必需的。您可以开始在用户名字段中放置电子邮件，但该字段只有30个字符，电子邮件可能在现实世界中很长。可能甚至比这里建议的75个字符更长，但是75个字符可以容纳最理想的电子邮件地址。问题是针对这种情况，正如基于电子邮件身份验证的应用程序遇到的。

Edit: Looking back on this after many months. For anyone who doesn't know the premise: Some apps don't have a requirement or desire to use a username, they use only email for registration & auth. Unfortunately in django auth.contrib, username is required. You could start putting emails in the username field, but the field is only 30 char and emails may be long in the real world. Potentially even longer than the 75 char suggested here, but 75 char accommodates most sane email addresses. The question is aimed at this situation, as encountered by email-auth-based applications.

推荐答案

有一种方法可以实现没有触摸核心模型，没有继承，但它绝对是黑客，我会非常小心使用它。

There's a way to achieve that without touching the core model, and without inheritance, but it's definitely hackish and I would use it with extra care.

如果你看看Django的文档 on signals ，你会看到有一个叫 class_prepared ，这是基本上发送一次任何实际的模型类已经由元类创建。那个时刻是在任何魔术发生之前修改任何模型的最后机会（即： ModelForm ， ModelAdmin ， syncdb 等等）。

If you look at Django's doc on signals, you'll see there's one called class_prepared, which is basically sent once any actual model class has been created by the metaclass. That moment is your last chance of modifying any model before any magic takes place (ie: ModelForm, ModelAdmin, syncdb, etc...).

所以计划很简单，你只是注册那个信号带有一个处理程序，它将检测何时被调用 User model，然后更改 max_length 属性用户名字段。

So the plan is simple, you just register that signal with a handler that will detect when it is called for the User model, and then change the max_length property of the username field.

现在的问题是，这段代码应该在哪里？它必须在用户模型加载之前执行，这样往往意味着很早就能使用。不幸的是，您不能（django 1.1.1 ，没有检查其他版本）将它放在设置中，因为导入信号会破坏事情。

Now the question is, where should this code lives? It has to be executed before the User model is loaded, so that often means very early. Unfortunately, you can't (django 1.1.1, haven't check with another version) put that in settings because importing signals there will break things.

一个更好的选择是将它放在一个虚拟应用的模型模块中，并将该应用在 INSTALLED_APPS list / tuple 之上（所以它在其他任何东西之前被导入）。以下是 myhackishfix_app / models.py 中可以使用的示例：

A better choice would be to put it in a dummy app's models module, and to put that app on top of the INSTALLED_APPS list/tuple (so it gets imported before anything else). Here is an example of what you can have in myhackishfix_app/models.py :

from django.db.models.signals import class_prepared

def longer_username(sender, *args, **kwargs):
    # You can't just do `if sender == django.contrib.auth.models.User`
    # because you would have to import the model
    # You have to test using __name__ and __module__
    if sender.__name__ == "User" and sender.__module__ == "django.contrib.auth.models":
        sender._meta.get_field("username").max_length = 75

class_prepared.connect(longer_username)

这将是诀窍。

几个笔记但是：

• 您可能还需要更改字段的 help_text 到反映新的最大长度


• 如果要使用自动管理员，您将不得不将 UserChangeForm ， UserCreationForm 和 Au thenticationForm ，因为最大长度不是从模型字段中推出的，而是直接在表单域声明中。

• You might want to change also the help_text of the field, to reflect the new maximum length
• If you want to use the automatic admin, you will have to subclass UserChangeForm, UserCreationForm and AuthenticationForm as the maximum length is not deduced from the model field, but directly in the form field declaration.

如果您使用 South ，则可以创建以下迁移以更改底层数据库中的列：

If you're using South, you can create the following migration to change the column in the underlying database:

import datetime
from south.db import db
from south.v2 import SchemaMigration
from django.db import models

class Migration(SchemaMigration):

    def forwards(self, orm):

        # Changing field 'User.username'
        db.alter_column('auth_user', 'username', models.CharField(max_length=75))


    def backwards(self, orm):

        # Changing field 'User.username'
        db.alter_column('auth_user', 'username', models.CharField(max_length=35))


    models = { 

# ... Copy the remainder of the file from the previous migration, being sure 
# to change the value for auth.user / usename / maxlength

这篇关于django的auth_user.username可以是varchar（75）吗？怎么办？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！