AutoField in CompositePrimaryKey

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

  1. #8576 - Remove the primary_key=True constraint from AutoField
  2. #35957 - Same, but also add a system check so AutoField must be part of a CompositePrimaryKey

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 AutoFields to a model:

  1. there’s no strong use case for doing this (see #8576)
  2. it’s only supported by PostgreSQL
  3. in PostgreSQL, AutoFields are IDENTITY columns
  4. is there a good reason to have multiple IDENTITY columns in a table?
  5. 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 AutoFields 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