#20846: Increase contrib.auth's User.username length
------------------------------+--------------------------------------
Reporter: ivoras@… | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
------------------------------+--------------------------------------
Comment (by hwkns):
Replying to [comment:14 freakboy3742]:
> To me, the idea of a > 30 character *username* is pretty laughable -
even *my* full name fits in 30 characters.
Frankly, the length of your own name is irrelevant. And being unable to
imagine the need for a username longer than 30 characters is **not** a
good reason to set that arbitrary limit.
> If we *are* going to do this, a max_length of 254 makes the most sense
to me (matching the length of the email field).
Yes, 254 makes sense if we're talking about using email addresses as
usernames, but that's still arbitrary. Why limit the length of `username`
in the model at all, when that can be easily accomplished in forms? Why
not use the largest maximum length for a `CharField` that is still
supported by all the database backends?
> I'm mostly bemused that people seem to have such an aversion to using
CUSTOM_USER_MODEL ...
Let me quote from the docs:
> **Warning:**
> Changing `AUTH_USER_MODEL` has a big effect on your database
structure. It changes the tables that are available, and it will affect
the construction of foreign keys and many-to-many relationships. If you
intend to set `AUTH_USER_MODEL`, you should set it before creating any
migrations or running `manage.py migrate` for the first time.
> Changing this setting after you have tables created is not supported
by `makemigrations` and will result in you having to manually fix your
schema, port your data from the old user table, and possibly manually
reapply some migrations.
I can't imagine why anyone would be averse to that...
> ... and that for some reason, using and/or contributing to a separate
username model app third-party project is considered harder than pushing a
patch into Django (a course of action that won't have practical results
for 6-12 months).
As it turns out, the mechanism used by the `longerusername` package to set
the `max_length` of `User.username` is not available in Django 1.7, so
yes, it is going to be considerably more difficult. Even if it weren't,
providing sensible defaults should be the goal of any good framework, so
pushing a patch into Django is a worthwhile pursuit.
--
Ticket URL: <https://code.djangoproject.com/ticket/20846#comment:15>
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/074.07fa7def73e0c298be92202bd7a24c71%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
