You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's only a feature request that would tidy up the generated graphql schema for deeply nested prisma models (depending on individual use cases). I am aware of the shield and the hooks properties in order to control access - but sometimes it would be helpful to consider this during the schema generation already in order to have a more lightweight schema.
It's some kind of follow-up of this issue: #111
Let's give me an example:
model ExampleTable {
id String @id @default(uuid())
name String
refTable RefTable[]
}
model RefTable {
id String @id @default(uuid())
name String
exampleTable ExampleTable @relation(fields: [exampleTableId], references: [id])
exampleTableId String
}
Currently the following two requests can't be handled:
The user should be able to create a RefTable record when using the ExampleTable model but not when using the RefTable model directly.
Example implementation:
/// @gql(fields: { refTable: {create: true}})
model ExampleTable {
id String @id @default(uuid())
name String
refTable RefTable[]
}
/// @gql(mutations: { create:null})
model RefTable {
id String @id @default(uuid())
name String
exampleTable ExampleTable @relation(fields: [exampleTableId], references: [id])
exampleTableId String
}
The user should be able to create a RefTable record only by using the RefTable model directly but not when using the ExampleTable model.
Example implementation:
/// @gql(fields: { refTable: {create: null}})
model ExampleTable {
id String @id @default(uuid())
name String
refTable RefTable[]
}
model RefTable {
id String @id @default(uuid())
name String
exampleTable ExampleTable @relation(fields: [exampleTableId], references: [id])
exampleTableId String
}
What do you think? Could you put it on the roadmap?
The text was updated successfully, but these errors were encountered:
It's only a feature request that would tidy up the generated graphql schema for deeply nested prisma models (depending on individual use cases). I am aware of the shield and the hooks properties in order to control access - but sometimes it would be helpful to consider this during the schema generation already in order to have a more lightweight schema.
It's some kind of follow-up of this issue: #111
Let's give me an example:
Currently the following two requests can't be handled:
Example implementation:
Example implementation:
What do you think? Could you put it on the roadmap?
The text was updated successfully, but these errors were encountered: