Skip to content

delete or disconnect related records #129

@macrozone

Description

@macrozone

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:

 customizeInputData: {
      MyResourceA: {
        update: (data, params) => {
          return renameDeep(data, (key) =>
            key === "disconnect" ? "delete" : key,
          )
        },
      },
    },

  • 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
     } 
   }
   }

}

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions