#19354: Unable to set PK for custom user model
-------------------------------------+-------------------------------------
Reporter: markteisman@… | Owner: nobody
Type: Bug | Status: new
Component: contrib.auth | Version:
Severity: Normal | 1.5-alpha-1
Keywords: PK Primary Key | Resolution:
Custom User | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by markteisman@…):
In my case it was in no way necessary, and I reverted to using {{{id}}} as
{{{pk}}}. To make sure the email address gets indexed I turned to
{{{db_index=True}}} instead.
I'm trying to think of reasons why to become id-agnostic though. What if
developers would be insistent in specifying a {{{pk}}}, and attempted to
solve the occurring issue by setting a non-unique {{{id}}}. The following
test may then pass for several distinct users:
{{{
if request.session[SESSION_KEY] != user.id:
# To avoid reusing another user's session, create a new, empty
# session if the existing session corresponds to a different
# authenticated user.
request.session.flush()
}}}
I suspect that this potentially could lead to unfortunate situations.
Relying on fields that are unique by definition this wouldn't pass(?)
In all honesty I'm quite a novice developer though, and I'm not sure if
this truly could lead to problems.
I've achieved my goal if I made you aware of this, so that you can make an
informed decision about what to do.
--
Ticket URL: <https://code.djangoproject.com/ticket/19354#comment:3>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
