Since CompositePrimaryKey
is already in core (#373), we need to reach a consensus on whether we want to add AutoField
support for it or not:
class User(Model):
pk = CompositePrimaryKey("tenant_id", "id")
tenant_id = CharField(max_length=255)
id = AutoField(unique=True)
We have 2 options
- #8576 - Remove the
primary_key=True
constraint fromAutoField
- #35957 - Same, but also add a system check so
AutoField
must be part of aCompositePrimaryKey
Another idea I had is to force AutoField
to set unique=True
& null=False
if primary_key=False
? IIRC this is required by MySQL for example
Why add restrictions?
If there’s no system check, it would mean users can add multiple AutoField
s to a model:
- there’s no strong use case for doing this (see #8576)
- it’s only supported by PostgreSQL
- in PostgreSQL,
AutoField
s areIDENTITY
columns - is there a good reason to have multiple
IDENTITY
columns in a table? - users are going to abuse this and use it for things it wasn’t meant for (which is to identify a row)
If AutoField
can be non-unique, that would mean two rows can have the same ID. I think it makes sense to think of AutoField
s as auto-incremented ID fields - if not for these restrictions, the concept of what an AutoField
is would change
It’s easier to remove restrictions than to add them, that’s why I opened #35957. If this ticket is accepted and we find a compelling use case for #8576 later, these restrictions can be removed
WDYT?
cc.
@charettes @nessita