Same field cannot have new resolver/type.

[maticzav]

# datamodel.graphql
type Post {
  id: ID! @unique
  createdAt: DateTime!
  updatedAt: DateTime!

  likes: [Like!]!
}

# schema.graphql
type Post {
  id: ID! @unique
  createdAt: DateTime!
  updatedAt: DateTime!

  likes: PostLikes!
}

type PostLikes {
  count: Int!
  liked_by_user: Boolean!
}

// Post.ts
export const Post = {
   likes: ({id}) => resolver
}

Query:

query Post {
   post(id: "cjclyohk3000h0192boujndcv") {
      id
      caption
      likes {
         liked_by_user
         count
      }
   }
}

The following query throws an error (type Like under likes should have selected sub-fields). I assume this happens because likes part of the query gets badly passed down to the binding, which then throws an error. Changing the name from likes to post_likes, for example, solves the problem, but I think it should work with the same name as well.

[marktani]

This might be related to #73 as well.

[kbrandwijk]

This is most probably an issue in the underlying graphql-binding. I will investigate, and move the issue if that turns out to be the case.

[kbrandwijk]

The current workaround is to use a different fieldname in your datamodel.

[maticzav]

Thanks, I’ll use the workaround. Do you maybe have any plans to fix this in near future/have idea about when this is going to be resolved?

[maticzav]

Fixed.

[maticzav]

Hey 👋,

It seems like this is still unresolved. @kbrandwijk, I think this concerns you the most since I think this is graphql-binding problem. I won't be able to present the actual problem we are having because it's part of the internal code but I'll try to create a reproduction example in the following days.

So, so far I've been able to figure out that fragments are poorly applied to nested fields or not at all in some very particular situations.

# schema.graphql

type User {
  id: ID!
  teaching_classrooms: UserTeachingClassrooms!
}

type UserStudyingClassrooms {
  classrooms: [Classroom!]!
  count: Int!
}

# This one works
query {
  viewer {
    user {
        teaching_classrooms {
        count
        classrooms {
          id
          name
        }
      }
    }
  }
}

# This one doesn't
query {
  viewer {
    user {
        teaching_classrooms {
        # count
        classrooms {
          id
          name
        }
      }
    }
  }
}

// resolvers.ts
export const UserTeachingClassrooms = {
  classrooms: {
    fragment: `fragment UserID on User { id }`,
    resolve: async ({ id }, args, ctx: Context, info) => {
      return ctx.db.query.classrooms(
        {
          where: { teacher: { id } },
        },
        info,
      )
    },
  },
  count: {
    fragment: `fragment UserID on User { id }`,
    resolve: async ({ id }, args, ctx: Context, info) => {
      const classrooms = await ctx.db.query.classroomsConnection(
        {
          where: { teacher: { id } },
        },
        ` { aggregate { count } } `,
      )

      return classrooms.aggregate.count
    },
  },
}

# Prisma forwarded first case - working
query ($_v0_where: UserWhereUniqueInput!) {
  user(where: $_v0_where) {
    teaching_classrooms {
      ... on Classroom {
        id
      }
    }
  }
}

# Prisma forwarded second case - error
query ($_v0_where: UserWhereUniqueInput!) {
  user(where: $_v0_where) {
    teaching_classrooms
  }
}

I think this is an issue with fragment application, but I am not 💯 sure yet. I'll try and look into this. It would be super helpful if you could explain the idea behind how fragments are applied because looking into the bare code and figuring out what it does takes me significantly more time compared to if I knew the idea behind it.

[divyenduz]

@maticzav : Are you on latest versions of binding libraries? If yes, can you please provide a minimal reproduction in form of a github project? Let us move this forward together.

A lot of fragment naming stuff was resolved in graphql-tools 3.x which should reflect in binding as well and this issue is worth revalidating.

This change log is a good summary of fixes in 3.x.x.

Thanks.

[maticzav]

Hey @divyenduz, yes, I think I am - my version of binding is 2.0.2 were the changes made in 2.1.0?

Besides that, I decided to solve the problem a bit differently. I am in a bit of a hurry with the current project so I might postpone this a bit - for about a week or so. But certainly, let's try to fix this together!

[divyenduz]

@maticzav : I tried to replicate this with the latest stack but so far no luck. Would be great if we can make a reproduction repo around this.

[divyenduz]

I have a reproduction here: https://github.com/divyenduz/prisma-binding-76

[kbrandwijk]

@divyenduz Looking at the repo example, I'm not sure if it's actually a clean reproduction. At least, if I understand the readme correctly, it fails with an invalid field. The example from @maticzav failed when there were no scalar fields present at a specific level. I'll try to look into it either.