Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

delete or disconnect related records #129

Open
macrozone opened this issue Mar 24, 2023 · 0 comments
Open

delete or disconnect related records #129

macrozone opened this issue Mar 24, 2023 · 0 comments

Comments

@macrozone
Copy link
Member

macrozone commented Mar 24, 2023

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

}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant