mavilein
commented
5 years ago Impact of Polymorphic Relations on the API
Generally speaking we need to enable polymorphic input types so that the user can choose which type should be affected by a mutation. But polymorphic input types are not possible in GraphQL. Therefore we try to emulate them through composition of existing input types. E.g.:
input FacebookUserCreateInput {
nick: String!
facebookId: String!
}
input GoogleUserCreateInput {
nick: String!
googleId: String!
}
# poor mans version of:
# type UserCreateInput = FacebookUserCreateInput | GoogleUserCreateInput
input UserCreateInput {
facebookUser: FacebookUserCreateInput
googleUser: GoogleUserCreateInput
}This way we can mostly rely on the validation of the GraphQL server for the schema. The only validation that we have to is that exactly one of the fields must be provided in the input type.
The following examples show GraphQL snippets for mutations to demonstrate the impact of polymorphic relations on Prismas OpenCRUD API.
Create
mutation {
createUser(
facebookUser: {
data: {
nick: "thezuck"
facebookId: "cjn0..."
}
}
){ id }
}Update
mutation {
updateUser(
facebookUser: {
where: { nick: "thezuck" }
data: { facebookId: "cjn0..." }
}
)
}{ id }Upsert
mutation {
upsertUser(
facebookUser: {
where: { nick: "thezuck" }
update: { facebookId: "cjn0..." }
create: { nick: "thezuck" facebookId: "cjn0..." }
}
)
}{ id }Nested Connect
mutation {
createComment(data:{
text: "this is a comment"
author: {
connect: {
facebookUser: { nick: "thezuck" }
# OR: googleUser: { nick: "pichi" }
}
}
})
}In the case of inheritance structures that specify a unique field on the inheritance type may also use the following:
mutation {
createComment(data:{
text: "this is a comment"
author: {
connect: {
user: { nick: "thezuck" }
}
}
})
}Nested Disconnect
for single relation fields
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
author: {
disconnect: true
}
}
)
}For list relation fields:
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
authors: {
disconnect: [
{ facebookUser: { nick: "thezuck" } },
{ googleUser: { nick: "pichi" } },
]
}
}
)
}In the case of inheritance structures that specify a unique field on the inheritance type may also use the following:
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
authors: {
disconnect: [
{ user: { nick: "pichi" } },
]
}
}
)
}Nested Create
mutation {
createComment(data:{
text: "this is a comment"
author: {
create: {
facebookUser: {
nick: "thezuck"
facebookId: "cjn0..."
}
}
}
})
}Nested Update
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
author: {
update: {
facebookUser: {
where: { nick: "thezuck" }
data: { facebookId: "cjn0..." }
}
}
}
}
)
}Nested Upsert
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
author: {
upsert: {
facebookUser: {
where: { nick: "thezuck" }
update: { facebookId: "cjn0..." }
create: { nick: "thezuck" facebookId: "cjn0..." }
}
}
}
}
)
}Nested Delete
for single relation fields
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
author: {
delete: true
}
}
)
}For list relation fields:
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
authors: {
delete: [
{ facebookUser: { nick: "thezuck" } },
{ googleUser: { nick: "pichi" } },
]
}
}
)
}In the case of inheritance structures that specify a unique field on the inheritance type may also use the following:
mutation {
updateComment(
where: { id: "cjn0..." }
data:{
text: "this is an updated comment"
authors: {
delete: [
{ user: { nick: "pichi" } },
]
}
}
)
}
williamluke4
Quadriphobs1
tjpeden
untouchable
schickling
jasonkuhrt
stevefan1999-personal
jnlsn
diversit
omar-rubix
nir-g
amille14
nikolasburk
This part of the spec describes the syntax for polymorphic relations. See the issue #3408 to learn about the other parts of the spec.
tables created with: https://stackedit.io/app
Introduction
Interfaces and unions are both a means to model polymorphic relations. Consider the following two examples. The first example shows a union can be used to model a polymorphic relationship where the types won't be stored in the same table/collection. The second example shows how the types can be stored within the same table/collection.
Example: Modeling a polymorphic relation with a union. In this case the types
FacebookUserandGoogleUserwill be stored within different tables/collections in the database. This approach is recommended if the types do not have much in common. This approach is very similar to Rails Active Record implementation for polymorphic relations.Example: Modeling a polymorphic relation with an interface. In this case the type
FacebookUserandGoogleUserinherit all the fields from the super typeUser. In this case the typesFacebookUserandGoogleUserwill be stored with a single table/collection calledUser. This approach is recommended if types share common fields and are often accessed together.The
inheritancedirectiveuserandusersquery.The
discriminatordirectiveinheritanceOn types
On interfaces and relation fields
discriminatorexists in the inheritance hierarchy.discriminator._discriminator, e.g.user_discriminator.A
typeunionuserorusersquery.Examples
A Union
In this example
FacebookUserandGoogleUserwould be stored in different tables or collections. The discriminator is stored in the relation link in this case.Semantic Subtleties:
authorin the tableCommentbecause it is referencing two tables.The resulting database schema would look like this:
An interface
In this example
FacebookUserandGoogleUserwould be stored in the same table or collection, which would contain the discriminator.Semantic Subtleties:
googleIdandfacebookIdwill not map to required columns in a SQL database. Prisma will guarantee that this constraint is met.The resulting database schema would look like this:
Polymorphic self relations
Polymorphic self relations are only possible with inheritance interfaces because unions do not define any common fields.
The resulting database schema would look like this: