#18085: sqllite integer is signed but django recognize as unsigned
-------------------------------+--------------------------------------
Reporter: robotr | Owner: nobody
Type: Bug | Status: closed
Component: Documentation | Version: 1.4
Severity: Normal | Resolution: worksforme
Keywords: tutorial | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by kmtracey):
That's a very puzzling traceback. What it shows happening is Django auth
code logging a user in (`auth_login(request, form.get_user())`), which
causes the user logged in signal to fire
(`user_logged_in.send(sender=user.__class__, request=request,
user=user)`), which has a receiver in the auth models file
(`update_last_login`) that sets the user's last login time to now and
saves the user. Now things start to get weird. The Django ORM level code,
instead of taking the path of saving an existing User model instance,
takes the path of inserting a new row into the auth_user table. This path
would ordinarily only be taken if the User instance primary key value was
not set, but it must be set since the User model was retrieved from the DB
earlier, and would not have been cleared by anything shown as installed in
the system (full traceback is showing only Django code installed). At any
rate this "new" user has an identical username to an existing user (likely
the one logging in!) so the DB raises an integrity error.
This is two people now reporting this exception on what looks to be some
version of Windows, Django 1.4.1, and Python 2.7.3. However I cannot
recreate it on my Windows7/Django1.4.1/Python2.7.3 machine. The original
report mentions 'the superuser id is "1", but as django said is
"4294967296" my superuser can not login' but does not give any details of
where that 42.. number was seen. It is a special number:
{{{
>>> hex(4294967296)
'0x100000000L'
>>>
}}}
1 in the high 32-bits of a 64-bit number, 0 in the low 32 bits, but how a
1 would get to be stored that way isn't clear to me. My best guess is
there is some 32-bit vs. 64-bit incompatibility in the underlying
Python/sqlite libraries installed. FWIW in my working setup I've got
64-bit Python installed on 64-bit Windows.
--
Ticket URL: <https://code.djangoproject.com/ticket/18085#comment:4>
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.
