Opened 11 years ago

Closed 11 years ago

#19619 closed Bug (duplicate)

BooleanField returning integer instead of Boolean

Reported by: Brian May Owned by: anonymous
Component: Database layer (models, ORM) Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


kg-test-debian ~ # dpkg -l python-django
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                         Version                      Description
ii  python-django                1.4.2-1~bpo60+2              High-level Python web development framework

My mysql table has:

CREATE TABLE `auth_user` (
  `username` varchar(30) NOT NULL,
  `first_name` varchar(30) NOT NULL,
  `last_name` varchar(30) NOT NULL,
  `email` varchar(75) NOT NULL,
  `password` varchar(128) NOT NULL,
  `is_staff` tinyint(1) NOT NULL,
  `is_active` tinyint(1) NOT NULL,
  `is_superuser` tinyint(1) NOT NULL,
  `last_login` datetime NOT NULL,
  `date_joined` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `username` (`username`)
In [10]: from django.contrib.auth import models
In [11]: a = models.User.objects.get(username="aleks")
In [12]: a.is_staff
Out[12]: False

Good. That is what I expected. If I try to retrieve it via another model however:

In [1]: from karaage.people.models import  Person
In [7]: p = Person.objects.get(user__username='aleks')
In [9]: p.user.is_staff
Out[9]: 0

(ignore gaps in sequence numbers, I was busy making typos)

OOops. Not good. This 0 means any checkbox set from this field will come out checked. Urgghh.

That person model is just:

class Person(models.Model):
    user = models.ForeignKey(User, unique=True)
    [... other attributes not used in this test ...]

I notice "sqlall" outputs bool instead of tinyint now in the SQL declaration, however I think it always use to be tinyint. So I think tinyint should still work.

Brian May

Change History (5)

comment:1 by Luke Plant, 11 years ago

This looks very similar to #15040, or at least could be fixed by the fix for that. Does this still happen with master?

comment:2 by Brian May, 11 years ago

Hmmm. Does seem very similar. Only I don't use select_related(...). Unless its use is somehow implicit.

Looks like my code breaks under git master, so I am going to have to fix some of these problems before I can test this.

comment:3 by Brian May, 11 years ago

So far it looks like the git master version does fix the problem.

comment:4 by marissaselfmadesf@…, 11 years ago

Owner: changed from nobody to anonymous
Status: newassigned

comment:5 by Simon Charette, 11 years ago

Resolution: duplicate
Status: assignedclosed

Thanks for reporting this but since it's fixed on master (f3a2bcdee906f7ca1434b6275fdc09b3a454cf46) and 1.5.X (f3a2bcdee906f7ca1434b6275fdc09b3a454cf46) I'll close as duplicate of #15040.

Note: See TracTickets for help on using tickets.
Back to Top