#36358 closed Bug (fixed)
Tables with composite primary keys including integer columns improperly get introspected as AutoField on SQLite
Reported by: | Simon Charette | Owned by: | Simon Charette |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 5.2 |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Given a models defined like
class CompositePk(models.Model): pk = models.CompositePrimaryKey("field1", "field2") field1 = models.IntegerField() field2 = models.IntegerField()
it incorrectly gets introspected as
class CompositePk(models.Model): pk = models.CompositePrimaryKey("field1", "field2") field1 = models.AutoField() field2 = models.IntegerField()
on SQLite which was missed by #36052 (a8e4fd11efc65832e7d9f5582d3868c5c8bd8d88) when support for composite primary introspection was added even if the pre-existing test encoded this qwirk.
This is likely due to the fact that SQLite surprisingly treats any integer field primary key as auto-incrementing even if not explicitly specified
In SQLite, a column with type
INTEGER PRIMARY KEY
is an alias for theROWID
(except inWITHOUT ROWID
tables) which is always a 64-bit signed integer.
which was known when AutoField
introspection was added in #23748 (a35d2a4510d5beec398b1007aaa26492d6aedf97) see ticket:23748#comment:11 but the override of get_field_type
was not properly adjusted when composite primary key introspection was added in #32234.
Marking as a release blocker as it's a bug in a newly released feature.
Change History (5)
comment:1 by , 6 weeks ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 6 weeks ago
Has patch: | set |
---|
comment:3 by , 6 weeks ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:4 by , 6 weeks ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
In 07100db6: