Opened 13 years ago

Last modified 21 months ago

#17337 new Bug

[nonrel] Support for non-integer AutoFields

Reported by: Jonas H. Owned by:
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords: nonrel
Cc: Brian Helba, raydeal Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


(This patch is part of the changes made to the inofficial fork "Django-nonrel" which adds basic support for non-relational databases.)

This patch adds basic support for non-integer primary keys. It works by not restricting primary keys to int and factoring out pk validation/type conversion into the backend.

Attachments (1)

nonint-autoid.patch (3.7 KB ) - added by Jonas H. 13 years ago.

Download all attachments as: .zip

Change History (13)

by Jonas H., 13 years ago

Attachment: nonint-autoid.patch added

comment:1 by Carl Meyer, 13 years ago

Triage Stage: UnreviewedAccepted

Accepting the ticket, as support for non-integer auto-fields is certainly desirable. I believe there's a different implementation of it in Alex Gaynor's 2010 GSoC code - I don't know which implementation is preferable.

comment:2 by Russell Keith-Magee, 13 years ago

IIRC, Alex's GSoC code punted on this issue (or, at least, had code that wasn't suitable for trunk), because we couldn't come up with a way to introduce it without introducing backwards incompatibilities. I seem to recall there were a bunch of places in the code that assumed that AutoFields were integers; however, it's been a while, so I might be mis-remembering.

comment:3 by Jonas H., 13 years ago

A few contrib apps assume PKs to be integers and also it gets tricky when it comes to testing with fixtures. Should we address all these issues at once or fix them bit by bit in multiple tickets?

comment:4 by Aymeric Augustin, 13 years ago

Type: UncategorizedBug

Two tickets (#17214, #17122) were recently reported about problems in the admin with models using non-integer primary keys. A quick search for "primary_key" turns up lots of other problems with non-integer primary keys. Clearly people are trying to use them, and as far as I can see, the docs don't forbid it.

Version 0, edited 13 years ago by Aymeric Augustin (next)

comment:5 by Aymeric Augustin, 13 years ago

Summary: [nonrel] Support for non-integer primary keys[nonrel] Support for non-integer automatic primary keys

comment:6 by Tim Graham, 11 years ago

Patch needs improvement: set

comment:7 by Collin Anderson, 9 years ago

Summary: [nonrel] Support for non-integer automatic primary keys[nonrel] Support for non-integer AutoFields

comment:8 by Nick Pope, 5 years ago

This is partially addressed by PR for #29979, but will further depend on #470 for default values for non-integer fields as well as #24042 for replacing isinstance(..., AutoField) checks.

comment:9 by Mariusz Felisiak <felisiak.mariusz@…>, 5 years ago

In 21e5594:

Fixed #29979, Refs #17337 -- Extracted AutoField field logic into a mixin and refactored AutoFields.

This reduces duplication by allowing AutoField, BigAutoField and
SmallAutoField to inherit from IntegerField, BigIntegerField and
SmallIntegerField respectively. Doing so also allows for enabling the
max_length warning check and minimum/maximum value validation for auto
fields, as well as providing a mixin that can be used for other possible
future auto field types such as a theoretical UUIDAutoField.

comment:10 by Brian Helba, 3 years ago

Cc: Brian Helba added

comment:11 by raydeal, 2 years ago

Owner: changed from nobody to raydeal
Status: newassigned

comment:12 by raydeal, 21 months ago

Cc: raydeal added
Owner: raydeal removed
Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top