How to manage relatedConnection for indirect relations with the prisma plugin?

[durdenx]

Is it possible to use nestedSelection for the relatedConnection method? If not what is the best way to manage indirect relations for a relay connection with prisma?

Currently i'm doing this (it's inside a Collection ObjectType):

  posts: t.prismaConnection({
    type: "Post",
    cursor: "id",
    resolve: async (query, parent, args, ctx) => {
      return ctx.db.post.findMany({
        ...query,
        where: { collections: { some: { post: { id: parent.id } } } },
      });
    },
  }),

Maybe there could be a more efficient way to do this with something like:

  posts: t.relatedConnection("posts", {
    cursor: "id",
    select: (args, ctx, nestedSelection) => ({
      posts: {
        select: {
          // This will look at what fields are queried on Media
          // and automatically select uploadedBy if that relation is requested
          post: nestedSelection(
            // This arument is the default query for the media relation
            // It could be something like: `{ select: { id: true } }` instead
            true
          ),
        },
      },
    }),
    resolve: (collection) => collection.posts.map(({ post }) => post),
  }),

[hayes]

working on a solution for this in #671, sorry I didn't respond here sooner. Will follow up with how to use this once its been finished up, there is still some work to do before its ready to go

[hayes]

Added some new helpers for this. Docs are available here: https://pothos-graphql.dev/docs/plugins/prisma#indirect-relations-as-connections

[hayes]

or with args:

[hayes]

obviously this isn't a great pattern, you would likely want an SortDirection enum or something similar, and maybe a SortBy enum for the different values you can sort on, but hopefully this is enough to get you going

[toxsick]

AHHH there it belongs ^^ SUPERDUPER, works perfectly. Thanks a lot and have a good weekend!

[toxsick]

Hey @hayes,

one more thing regarding the totalCount field, by adding the _count block in the select function:

This will always perform a count on the table, even if the totalCount field is not requested in the query. In my case this has a pretty significant performance hit (5ms VS 1976ms).

Can you think of a way to include the _count only if the totalCount field is requested?

regards

[hayes]

You could just move the query into the totalCount resolver. If you aren't filtering or reusing the connection that should work fine.

The 2 other options are to make totalCount a function on the returned connection object that can load the count (this allows you to access args for the connection) and then call that function in the totalCount resolver. Or you can use the info arg to look for a selection of the count field to conditionally select the count. This can get slightly complex, but if you don't need to worry about fragments it's pretty easy