#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 freakboy3742):
Replying to [comment:8 carljm]:
> That said, I do think that the overly-restrictive max-lengths in the
default user model should be fixed, custom-user-models notwithstanding,
and that built-in migrations should make it possible to fix. Russell, it
sounds like you agree, at least in theory? Could we reflect that consensus
by reopening this ticket?
Now that we actually *have* a migration system, I agree that the
discussion has moved from being a practical impossibility to at least a
plausible option.
However: To me, the idea of a > 30 character *username* is pretty
laughable - even *my* full name fits in 30 characters. The idea that,
using the classical definition a username, a user would select a username
> 30 seems like a pretty unusual case to me. IMHO, increasing to some
arbitrary other value (60, 150, whatever) to support some arbitrary
concept of what "big enough" will mean for usernames seems like a waste of
effort. 30 is a reasonable default, and we have custom user models if you
really do need something different.
Of course, that doesn't allow for the case where someone is using
"username" to store something that wouldn't classically be called a
"username" - the "email address as username" case, for example. I have
some mild reservations about that as a design pattern - if you want to log
in by email, then a custom user model with USERNAME_FIELD='email' is a
much better solution to me. We added custom user models for a reason -
trying to bash every possible use case into Django's default user model is
just wrong-headed.
To be clear, though: I'm not morally opposed to making a change to
max_length. I'm mostly bemused that people seem to have such an aversion
to using CUSTOM_USER_MODEL, 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).
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).
> It occurs to me that custom user models may actually prove an obstacle
to fixing this in a much more direct way, in that fixing it will likely
change the abstract base models that many custom user models are
inheriting from, and we can't ship a migration to change someone's custom
user model. I guess if we start to allow shadowing of fields on abstract
bases, as has been discussed recently on the mailing list, we could make
this change only on the final concrete User model, and leave the abstract
bases alone, for backwards-compatibility. But then future custom user
models inheriting from those bases won't benefit from the change...
Agreed that this is a complication. Anyone deploying a third party custom-
user app will need to have migrations. The application of those migrations
will need to be Django-version dependent. If you're using the custom app
on Django 1.7, you won't need to migrate the third party app - but as soon
as you upgrade Django, the third party app will need to run the 1.7->1.8
migration.
--
Ticket URL: <https://code.djangoproject.com/ticket/20846#comment:14>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/074.2c2793936dd25a9f189b0f356367ced2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
