User.username max_length 254

[Collin Anderson]

Hi All,

I was reminded by:

Allow shadowing of abstract fields https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ

and https://code.djangoproject.com/ticket/24288 (Custom User Models for small tweaks).

Could we reopen https://code.djangoproject.com/ticket/20846 and increase User.username max_length to 254?

Personally, that's the only thing I've ever needed to change about my User class. I just need it long enough to hold email addresses. I've seen many other people wanting the same thing.

In 1.8 we migrated the length of EmailField from 75 to 254, so it should be almost™ as easy to change the username field.

If needed, we could keep the 30-character limit on UserCreationForm and UserChangeForm for backwards compatibility. The limit in the database is the real killer :) Though, consistency is also nice.

Thanks,

Collin

[Wim Feijen]

Hi Collin,

I would like that, good idea! 

Wim

[Daniel Hawkins]

Yes please!  Since contrib.auth.models.User.email is an EmailField, that change will require everyone to run a migration, right?  Then we might as well change the character limit on the username field at the same time, no?  And any other defaults that might be less-than-reasonable?

I was going to update the longerusername package by adding a Django 1.7 migration, but it seems I can't alter fields on the User model from within another app's migrations in Django 1.7.  This was possible with South, but it appears to be impossible with Django migrations (except perhaps with raw SQL, which seems like a bad idea).  So now I have to create a custom user model just so I can migrate to Django 1.7 (which I have to do in order to continue getting security releases after 1.8 is released).

According to the docs, setting a custom user model after you've already run initial migrations is not supported (https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).  So, for anyone without a custom user model, who is already running on Django 1.7 in production, who would like to have usernames longer than 30 characters, there is no way to make that happen.

[Daniel Hawkins]

Beta 1 marks the end of any changes that aren't considered release blocking bugs. A bug is a "Release blocker" if it's a regression from a previous version of Django or if it's an important bug in a new feature.

... so I guess the ship has sailed on this idea?  :(

[Collin Anderson]

Hi,

I'm actually about to run into a similar situation myself where I already have migrations for my project but need to start using a custom user model (because I need a longer username :).

There's talk of possibly including a custom user in the project template https://code.djangoproject.com/ticket/24370. However, I think we need to at least document how to hack your project so you can switch to a custom user after using migrations.

Collin

[Tim Graham]

Well, this change wouldn't have been made after alpha (feature-freeze) either. As there haven't been any outright rejections of the idea, I think the next step is for someone to write a patch and carefully consider and document and backwards compatibility concerns.

[Chris Foresman]

Given that 1.8 is an LTS, and increasing the default username length addresses the 80% use-case for custom user models, isn't it worth adding this change now (even if it philosophically violates the alpha/beta split)?

[Josh Smeaton]

As Tim pointed out, it's unlikely that the change would have made Alpha, let alone Beta. Adding a new feature now breaks the 'philosophical' release rules but it also allows a feature through without the wider community testing in alpha and beta (now that it's cut). As far as I can tell, increasing the length of the field only really affects existing deployments without a custom user model. New deployments are free to implement custom user models if they require different constraints.

So the set of users with existing deployments without a custom user model would probably make up at least 80%, but I'd bet an extremely large portion of those users don't absolutely have to have an increased username field. They've gone this long without it. Breaking the release rules to push a change that'll affect such a large segment of the community isn't going to fly.

Cheers

[Daniel Hawkins]

I'd bet an extremely large portion of those users don't absolutely have to have an increased username field. They've gone this long without it.

They (we) have gone this long, not because we didn't need it, but because we didn't think of it in the very beginning, and after that it was too late.  The portion of users this would affect is exactly the same as the set that is affected by the change in max_length on the User.email field, which is already part of 1.8.  Given that fact, I don't see this as a very big violation of the alpha/beta testing process.

[Chris Foresman]

Yeah, this is the point I was trying to make. I absolutely get your point about the impact to user, though, Josh. It just seems worth doing since this is an LTS release.

[Collin Anderson]

Hi All,

I made a pull request. https://github.com/django/django/pull/4250/files

I wish I would have thought of this two months ago, but I think it's too big of a change to get into 1.8 this late. I personally don't want to potentially have the release delayed because of possible issues with this change.

Collin

[Collin Anderson]

Hi All,

I'm pretty busy right now and don't currently have the time and motivation to finish this username max_length 254 change. If anyone wants to finish it up, the PR is nearly complete; it just needs better instructions on how to keep the limit at 30 characters for anyone who doesn't want the behavior to change.

https://github.com/django/django/pull/4250/files

My excuse :)

There's been some re-organization at work over the last month and I'm now basically running a one-man web development business, so it's been pretty busy. :) I'm also no longer responsible for the project that needed this change the most, hence the loss of motivation on this one. :)

Thanks,

Collin

[Micah Hausler]

I actually migrated my site to 1.7 and added a custom user model very easily. Here's a gist with the code, https://gist.github.com/micahhausler/63636f26cc87bb966218, but essentially all I had to do was add a new user app, copy the Django AbstractUser code, and set the db_table to 'auth_user'.

class User(AbstractBaseUser, PermissionsMixin):
 
    objects = UserManager()
 
    class Meta:
        db_table = 'auth_user'

Does anyone think this method could be worth adding to the Django documentation? I'd be happy to open a ticket/write the docs. The only side effect would be that if someone were using content-types for auth_user objects, that would need to be migrated.

 

Micah Hausler

[Ryan Floyd]

I solved this in a very hacky way, without touching any django code. I'll probably break the forms

1. Create an empty migration (python manage.py makemigrations --name extend_username_field --empty [app_name])

2. Inside the migration, add:

```

operations = [

    migrations.RunSQL('ALTER TABLE auth_user ALTER COLUMN username TYPE varchar(254);')

]

```

Works so far, but haven't really tested it extensively

-Ryan

[Anders Petersson]

Hey, I would like to see this get into 1.9,

Can anyone suggest whats needed to merge https://github.com/django/django/pull/4250 ?

[Collin Anderson]

Hi Anders,

I think we need to make it as easy as possible for people to add back the 30-character restriction if they want, especially in the admin. Really good documentation of what to do should be good enough I hope, but we need to make sure it's easy and there aren't too many side-effects.

Thanks,

Collin

[Dheerendra Rathor]

Hello All,

Since username length is going to increased from 30 to 254 (PR #5497), I personally think first_name and last_name field length should be increased as well. Practically many first names are of length > 30, this is quite common in southern India (https://www.quora.com/Why-are-South-Indian-names-often-long). IMHO these fields should be increased to 254 as well.