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
if you have model A has many B and use the current (nexus)-crud api, there are two ways to remove an item B from A: by either disconnect it or delete it.
disconnecting it only works if any B can live on its own, wheras deleting them is correct if B is part of A and cannot live on its own.
at least in german, we call the case where B can live without A, an "aggregation" relation ship, whereas when B cannot live without A, its a "composition".
the generated crud api from nexus-prisma exposes both ways, even if disconnecting does not work, as it would leave items B as orphans and that could be prevented by restrictions in the schema.
our dataprovider always default to disconnect if that is available and uses delete if there is no disconnect on the introspection.
Now if you have the situation that disconnect does not work, its a bit annoying to deal with this. Here are some things you can do in this case:
try to remove disconnect from the update input types on the backend. This is described by @hajnalben in Deleting relations if disconnect operation is not present #79 and he also added some methods to do so for the tests, but its a bit awkard and requires internals of nexus-plugin-prisma
other backends might have better control over that, i am not sure. Nexus-plugin-prisma is anyway deprecated. If you create the backend api more manually, you can make a more concious decision here and not include disconnect
still it could be that both disconnect and delete could be correct and it depends on the usecase. So handling it on the client might be better:
you can use customizeInputData to replace disconnect with delete. A very dirty and brute force (but working) way is this:
we could think about how to do it more fine tuned. E.g. we could try to add customization on how relations are handled. E.g. as described here Idea: rework resource dependent options #128 we could reorganize the options to be more centered around resources and then do something like:
resources: {
MyResourceA: {
// other options like fragments...
relations: {
MyResourceB: {
type: "composition" // something that describes that B cannot live without A and should be deleted. It would default to "aggregation" if not specified, which means to disconnect
}
}
}
}
The text was updated successfully, but these errors were encountered:
if you have model
A has many B
and use the current (nexus)-crud api, there are two ways to remove an item B from A: by either disconnect it or delete it.disconnecting it only works if any B can live on its own, wheras deleting them is correct if B is part of A and cannot live on its own.
at least in german, we call the case where B can live without A, an "aggregation" relation ship, whereas when B cannot live without A, its a "composition".
the generated crud api from nexus-prisma exposes both ways, even if disconnecting does not work, as it would leave items B as orphans and that could be prevented by restrictions in the schema.
our dataprovider always default to
disconnect
if that is available and usesdelete
if there is nodisconnect
on the introspection.Now if you have the situation that
disconnect
does not work, its a bit annoying to deal with this. Here are some things you can do in this case:disconnect
from the update input types on the backend. This is described by @hajnalben in Deleting relations if disconnect operation is not present #79 and he also added some methods to do so for the tests, but its a bit awkard and requires internals of nexus-plugin-prismadisconnect
still it could be that both
disconnect
anddelete
could be correct and it depends on the usecase. So handling it on the client might be better:customizeInputData
to replace disconnect with delete. A very dirty and brute force (but working) way is this:The text was updated successfully, but these errors were encountered: