Cascade Deletion Does Not Fire Subscriptions

[goulderb]

Describe the bug When a relationship is setup with cascade deletion, subscriptions will not be fired if the record which has the relationship on it is deleted.

To Reproduce Steps to reproduce the behavior:

1. Create a new project with prisma init
2. Paste the following into the datamodel.prisma file:

   
   type A {
   id: ID! @unique
   name: String!
   bs: [B!]! @relation(name: "AtoB", onDelete: CASCADE)
   }

type B { id: ID! @unique name: String! }

3. Deploy this schema via prisma deploy
4. Open the playground at localhost:4466
5. Create a subscription on type B:
```graphql
subscription {
  b {
    mutation
    node {
      id
      name
    }
    previousValues {
      id
      name
    }
    updatedFields
  }
}

6. In a separate tab, create a record of type A and use nested mutations to create some records of type B:

   mutation {
   createA(data: {
   name: "Test A",
   bs: {
     create: [
       {
         name: "Test B 1"
       },
       {
         name: "Test B 2"
       }
     ]
   }
   }) {
   id
   }
   }

7. Observe that the subscription shows both B's being created
8. Delete the record created earlier:

   mutation {
   deleteA(where: {
   id: "<ID GOES HERE>"
   }) {
   id
   }
   }

9. Observe that the subscription is not fired for each of the deletions that took place.

Expected behavior The subscription would fire for each of the deleted records of type B, as it would if they were deleted or created through other means.

Versions (please complete the following information):

• OS: Arch Linux
• prisma CLI: prisma/1.18.0 (linux-x64) node-v10.11.0
• Prisma Server: 1.18.0

[goulderb]

@marktani Could you please explain how this is a "feature"? In my view, this is a bug since subscriptions do not do what they say they do on the tin.

I'd also apply the same logic to updateMany/deleteMany, since these are parts of the public prisma API.

[marktani]

Sure, I'd love to.

The proposed behaviour is a feature that has not been implemented yet, rather than something that has already been implemented but doesn't work as intended. In other words, it's a known limitation rather than a bug. I'm not a big fan of hair splitting terminology: to me personally, there is no big difference between calling this a bug or a feature, but you asked me and this is my answer.

The current behaviour is mentioned in the docs. Is there a place where it is mentioned that batch mutations fire subscriptions? Then it should be updated and pointed to this feature request.

[marktani]

Just saw that the section I linked to is about batch mutations not cascading deletes. I added a similar note for cascading deletes to the docs.

[goulderb]

@marktani Thank you very much for the explanation. For my team, these features are essential since we are building all of our business logic as asynchronous actions triggered off from updates to our data. The current limitations around subscriptions make them extremely unreliable and forces us to use prisma in extremely inefficient ways (sending many individual create/update/delete requests). This wrecks performance for cases where we need to create/update/delete many records at once, which is fairly common in our application.

For me, the distinction between something being a "bug" and something being a "feature" for prisma is essentially this (I apologize for this sounding particularly harsh): Is it going to be addressed in a timely manner or wither and die?

Bugs, in my experience so far, have been tackled quite quickly. Myself and my team have been extremely impressed with the turnaround time on bug reports. Feature requests, on the other hand, sit in limbo for months with no activity/news from the prisma team. For example, right now there are two tickets marked "roadmap/2018-Q3" for new features that have not been released and no update has been given on the tickets, even with community members asking for such updates.

I hope that the prisma team can work on addressing these issues through better communication with the community, as additional responsiveness and insight into what is being worked on would go a long way towards alleviating concerns about whether or not it is wise to build a product on top of prisma.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[gabrieltong]

Hey @marktani I face the same problem , our system has race of resource update, and I need to do like

updateUser({
data: {
  state: "B"
},
where: {
  id: id,
  state: "A"
}

but prisma need unique where when updateUser, so I need to user

updateManyUsers({
data: {
  state: "B"
},
where: {
  id: id,
  state: "A"
}

I think a need a NotUniqueWhere when updateUser or updateManyUsers to fire subscription

[RoMay]

Yeah, any change to see it implemented soon? Without subscription on batch operation, we have to loop through the referenced nodes and update each of them separately.