[Django] #35957: Allow AutoFields in composite primary keys

Django

unread,

Nov 29, 2024, 7:53:58 PM11/29/24

to django-...@googlegroups.com

#35957: Allow AutoFields in composite primary keys
-------------------------------------+-------------------------------------
Reporter: Csirmaz Bendegúz | Type: New
| feature
Status: new | Component: Database
| layer (models, ORM)
Version: dev | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
This is a follow up to #373 (''CompositePrimaryKey''), #8576 (''Multiple
AutoFields in a model''), #27452 (''SerialField'').

At the moment, `AutoField`s must set `primary_key=True`.

This makes it impossible to use them with `CompositePrimaryKey`.

''Multiple AutoFields in a model'' (#8576) may not be useful, but having
an `AutoField` be part of a composite primary key has its uses. It's good
practice to use surrogate keys, even if the table has a composite primary
key (should this surrogate key be an auto-incremented field is another
discussion).

So I think we should allow `AutoField`s to not set `primary_key=True` if
they are part of a composite primary key.

Note: SQLite doesn't support AutoFields in composite primary keys.
--
Ticket URL: <https://code.djangoproject.com/ticket/35957>
Django <https://code.djangoproject.com/>
The web framework for perfectionists with deadlines.

Django

unread,

Dec 2, 2024, 12:05:35 PM12/2/24

to django-...@googlegroups.com

#35957: Allow AutoFields in composite primary keys
-------------------------------------+-------------------------------------

Reporter: Csirmaz Bendegúz | Owner: (none)

Type: New feature | Status: new

Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Natalia Bidart):

* stage: Unreviewed => Accepted

Comment:

Hello Ben, thank for your creating this follow up ticket. I'm accepting
this because of what was discussed and agreed in
[https://forum.djangoproject.com/t/serialfields-yay-or-nay/32541/21 this
Forum comment], but I do have a clarification question: in the Forum
conversation, I understand it boiled down to two options:

> Item (1) is tracked in ticket-8576, which is open but in a “Design
Decision Needed” triage state. Allowing primary_key=False in an AutoField
would enable all DB backends except SQLite to use such a field as part of
a composite primary key. However, no backend except PostgreSQL supports
having more than one AutoField. To progress this ticket, we need someone
to take ownership and propose an outline for the implementation, so it can
be moved to “Accepted” and enter the review process. Given the nature of
the change, I fear this may be a longer and slower process.
> On the other hand, I see value in having a way to define DB-level
“counters” (independent of composite PKs), which is what item (2)
addresses. Only PostgreSQL supports this, so I would prefer a PostgreSQL-
specific field for this feature. While serial is no longer recommended, a
GeneratedIdentityField in django.contrib.postgres, as suggested by Simon,
seems like a promising alternative and could be more actionable in the
short term. I recommend reopening ticket-27452 and repurposing it for this
feature.

If I understand correctly, this ticket would be solving item (2) above, so
we would be providing a Postgresql-specific field, correct?
--
Ticket URL: <https://code.djangoproject.com/ticket/35957#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

Dec 3, 2024, 4:04:13 AM12/3/24

to django-...@googlegroups.com

#35957: Allow AutoFields in composite primary keys
-------------------------------------+-------------------------------------
Reporter: Csirmaz Bendegúz | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Csirmaz Bendegúz):

No, it's the opposite. The goal is to make `AutoField`s work with
composite primary keys. It's not Postgres-specific, this would work with
all database backends (except SQLite).

The difference between #8576 and this is that this ticket won't allow
multiple `AutoField`s. A model can only have one `AutoField`, and that
`AutoField` must be a primary key, or must be part of a composite primary
key.

e.g.:

{{{
class Foo(models.Model):
pk = models.CompositePrimaryKey("bar", "id", primary_key=True)
bar = models.CharField(max_length=255)
id = models.AutoField()
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/35957#comment:2>

Django

unread,

Dec 3, 2024, 9:36:08 AM12/3/24

to django-...@googlegroups.com

#35957: Allow AutoFields in composite primary keys
-------------------------------------+-------------------------------------
Reporter: Csirmaz Bendegúz | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Natalia Bidart):

* cc: Simon Charette, Lily Foote (added)

Comment:

Thank you Ben for clarifying. This seems to be outside what we discussed
in the forum. Do you have more resources to point me to understand the
bigger picture? I was assuming that our agreement and path forward with
`AutoField`s was described in the referenced forum post but before
proceeding I would like to have the full context.
--
Ticket URL: <https://code.djangoproject.com/ticket/35957#comment:3>

Django

unread,

Dec 4, 2024, 12:21:53 AM12/4/24

to django-...@googlegroups.com

#35957: Allow AutoFields in composite primary keys
-------------------------------------+-------------------------------------
Reporter: Csirmaz Bendegúz | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Csirmaz Bendegúz):

I think it aligns with what we discussed on the forum?

We keep the ''one AutoField per model'' restriction we currently have, but
we'll allow `AutoField` to be part of a composite primary key.

I don't think we should allow multiple `AutoField`s, since only Postgres
would support that and there's no strong use case for having multiple
IDENTITY columns in a table. If consensus on this changes, then #8576 can
be re-opened any time as it doesn't conflict with this ticket.

While the ''multiple AutoFields'' topic is contentious, everyone seems to
agree that ''AutoField in composite primary keys'' should be added.
--
Ticket URL: <https://code.djangoproject.com/ticket/35957#comment:4>

unread,

Jun 23, 2025, 10:32:32 AM6/23/25

to django-...@googlegroups.com

#35957: Allow AutoFields in composite primary keys
-------------------------------------+-------------------------------------

Reporter: Csirmaz Bendegúz | Owner: David
| Sanders
Type: New feature | Status: assigned

Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted

Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by David Sanders):

* has_patch: 0 => 1
* owner: (none) => David Sanders
* status: new => assigned

Comment:

I have a PR up but I need clarification on a couple of things (see
comments in PR) - but mainly how do we get the test runner to skip checks
for a model if said model has `requires_db_features` set.
--
Ticket URL: <https://code.djangoproject.com/ticket/35957#comment:10>

Django

unread,

Jun 24, 2025, 3:57:35 AM6/24/25

to django-...@googlegroups.com

Needs tests: 0 | Patch needs improvement: 1

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by David Sanders):

* needs_better_patch: 0 => 1

--
Ticket URL: <https://code.djangoproject.com/ticket/35957#comment:11>

Reply all

Reply to author

Forward