https://www.prisma.io/ logo
Join SlackCommunities
Powered by
# orm-help
  • i
    well i guess when the client is restarted initially you can just check if stuff was deleted. then continue listening
  • j
    how do i check if stuff was deleted when i was not listening if it’s gone when i connect again? ( are you saying the subscriber should have it’s own copy of the prisma state to be able to diff whats missing from the db at start?)
  • j
    when we issue a delete mutation it gets removed from the database so how would i get the info that those records were removed when i re-subscribe
  • j
    what we need to achieve is a reliable and durable way to notify a external service that something was updated/created/deleted in prisma. pref a catchup mechanic or a transaction log of whats been deleted so we don’t miss them and the external service becomes out of sync
  • j
    what we have came up with so far was creating a DB trigger that on update, delete and insert for a specific table, insert a change record in a auxiliary table, then have a daemon read from that table and perform webhooks to the external service. this would ensure durability and we won’t miss any updates since it’s done in the DB and if the DB isn’t running. nothing is modifying anyway.
  • j
    But as you can probably see, that is not pretty at all and requires making a new custom service and ad-hoc triggers in the DB
  • i
    well another way i guess is you can create an intermediate service that checks if the subscribed users have received published subscriptions of not then, i guess the client checks if it has any new subscriptions or messages on the service''s queue/table. so mybe once the client receives and confirm you can delete the records.
  • j
  • j
    so i guess Subscriptions is totally of the table
  • j
  • j
    updateMany and deleteMany Mutations Do Not Fire Subscriptions
  • j
    https://github.com/prisma/prisma/issues/3303 
    Cascade Deletion Does Not Fire Subscriptions
  • j
    https://github.com/prisma/prisma/issues/2327 
    Currently, batch mutations don't fire subscription events.
  • i
    well you can also create custom subscriptions
  • j
    do elaborate please
  • i
  • j
    so you are saying that by creating the subscription in the server and not just via the client we won’t be affected by the bugs above where it does not fire under load or updateMany, deleteMany & during batch mutations?
  • j
    and how would it become durable this time?
  • j
    as in. how do we get notified about stuff that got deleted when the subscriber wasn’t connected as they are no longer in the database when it reconnects
  • i
    that will depend on how the custom subscriptions are implemented
  • j
    could you be more specific please
  • j
    tkae this example
    Copy code
    const resolvers = {
  Query: {
    // ... like before
  },
  Mutation: {
    // ... like before
  },
  Subscription: {
    publications: {
      // ... like before
    },
    postDeleted: {
      subscribe: (parent, args, ctx, info) => {
        const selectionSet = `{ previousValues { id title } }`
        return <http://ctx.db.subscription.post|ctx.db.subscription.post>(
          {
            where: {
              mutation_in: ['DELETED'],
            },
          },
          selectionSet,
        )
      },
      resolve: (payload, args, context, info) => {
        return payload ? payload.post.previousValues : payload
      },
    },
  },
}
  • j
    are you saying we should insert code here that does things to make it durable?
  • i
    yes you can create checks/validations in here before execution
  • j
    ok, but will these fire even if there actually isn’t anyone connected to the subscription?
  • i
    u could also store the events in a table/log, then wen the clients start up it checks the events on the table/log
  • j
    ok, then i just have one final question
  • j
    if we do this
  • j
    how do we make sure it only triggers once
  • j
    say we are running 6x of the application and 3x of prisma
1...319320321...637Latest