[FEATURE] - Support custom primary key field instead of `id` in NextAdminOptions

[helloitsmix]

Summary

Currently, next-admin seems to assume that the primary key of each model is always named id. However, it is fairly common in Prisma schemas to use a different field name as the primary key, or to reference a unique field (other than id) in a relation.

It would be great to have a way to tell next-admin which field should be treated as the primary key for a given model — either globally or per-model via NextAdminOptions.

If there is already a way to handle this, I'd love to know — I couldn't find anything in the documentation!

Basic Example

Consider the following Prisma schema:

model Carriera {
  id  Int    @id @default(autoincrement())
  key String @unique

  nome            String
  descrizione     String?
  abilitaCarriere AbilitaCarriera[]

  @@map("carriere")
}

model Abilita {
  id  Int    @id @default(autoincrement())
  key String @unique

  nome            String
  descrizione     String?
  abilitaCarriere AbilitaCarriera[]

  @@map("abilita")
}

model AbilitaCarriera {
  possibilita Int?

  carriera    Carriera @relation(fields: [carrieraKey], references: [key])
  carrieraKey String
  abilita     Abilita  @relation(fields: [abilitaKey], references: [key])
  abilitaKey  String

  @@id([carrieraKey, abilitaKey])
  @@map("abilita_carriere")
}

Here, AbilitaCarriera has a composite primary key (carrieraKey + abilitaKey) and the relations point to the key field (not id) of the related models. Operations on this model currently fail because next-admin looks for an id field that is not used in this context.

A possible solution could be a new option in NextAdminOptions, for example:

const options: NextAdminOptions = {
  models: {
    AbilitaCarriera: {
      primaryKey: ['carrieraKey', 'abilitaKey'], // composite key support
    },
    Carriera: {
      primaryKey: 'key', // custom single key
    },
  },
};

Drawbacks

No response

Unresolved questions

• Is there already a supported way to configure a custom or composite primary key in next-admin? If so, could it be better documented?
• Should composite primary keys be serialized in a specific way for URL routing (e.g., carrieraKey__abilitaKey)?
• How should the edit/delete actions behave when the primary key is composite?

[foyarash]

Hello @helloitsmix

We actually infer primary keys from the generator, though it seems we dont handle well composite keys.
If you want to dig into the issue, a PR is greatly appreciated. Here are some files you can have a look at:

next-admin/packages/generator-prisma/src/dmmf.ts

Line 97 in 6c43e72

name: dmmfModel.primaryKey.fields.join("_"),

next-admin/packages/next-admin/src/utils/jsonSchema.ts

Line 79 in 6c43e72

return propertyData?.__nextadmin?.primaryKey;

next-admin/packages/next-admin/src/utils/server.ts

Line 101 in 6c43e72

export const getModelIdProperty = (model: ModelName) => {

[helloitsmix]

Thanks for the quick response and for pointing out the relevant files! Unfortunately I don't have the bandwidth to work on a PR right now, but I hope this issue can serve as a useful reference for anyone who wants to tackle it. Thanks again for the great work on the project! 🙏

[helloitsmix]

In case anyone is interested, I managed to get it working with an explicit many-to-many relation this way; unfortunately, I couldn't get it working with an explicit self-referential many-to-many relation.

To be precise: creating entries directly in the self-referential table works, creating entries from the related tables doesn't.

Schema:

model Abilita {
  id  Int    @id @default(autoincrement())
  key String @unique

  carriere AbilitaCarriera[]

  @@map("abilita")
}

model Carriera {
  id           Int      @id @default(autoincrement())
  key          String   @unique
  
  abilita           AbilitaCarriera[]
 
  entrate           TransizioneCarriera[] @relation("entrate_carriera")
  uscite            TransizioneCarriera[] @relation("uscite_carriera")

  @@map("carriere")
}

// Working explicit many-to-many relation
model AbilitaCarriera {
  id Int @unique @default(autoincrement())

  abilitaId  Int      @map("abilita_id")
  abilita    Abilita  @relation(fields: [abilitaId], references: [id], onDelete: Cascade)
  carrieraId Int      @map("carriera_id")
  carriera   Carriera @relation(fields: [carrieraId], references: [id], onDelete: Cascade)

  @@id([abilitaId, carrieraId])
  @@map("abilita_carriere")
}

// Not workling explicit self-referential many-to-many relation
model TransizioneCarriera {
  id Int @unique @default(autoincrement())

  daCarrieraId    Int      @map("da_carriera_id")
  daCarriera      Carriera @relation("entrate_carriera", fields: [daCarrieraId], references: [id])
  versoCarrieraId Int      @map("verso_carriera_id")
  versoCarriera   Carriera @relation("uscite_carriera", fields: [versoCarrieraId], references: [id])

  @@id([daCarrieraId, versoCarrieraId])
  @@map("transizioni_carriera")
}

Next admin options:

export const options: NextAdminOptions = {
  model: {
    Carriera: {
      edit: {
        fields: {
          abilita: {
            relationOptionFormatter: (item) => item.key,
            display: 'list',
            relationshipSearchField: 'abilita',
          },
        },
      },
    },
    Abilita: {
      edit: {
        fields: {
          carriere: {
            relationOptionFormatter: (item) => item.key,
            display: 'list',
            relationshipSearchField: 'carriera',
          },
        },
      },
    },
    AbilitaCarriera: {
      list: {
        search: ['carriera.key', 'abilita.key'],
        fields: {
          carriera: {
            formatter: (item) => item.key,
          },
          abilita: {
            formatter: (item) => item.key,
          },
        },
      },
    },
  },
};