Same field cannot have new resolver/type. about prisma-binding HOT 11 OPEN

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.

from prisma-binding.

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

from prisma-binding.

@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.

from prisma-binding.

This might be related to #73 as well.

from prisma-binding.

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

from prisma-binding.

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?

from prisma-binding.

Fixed.

from prisma-binding.

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.

from prisma-binding.

@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.

from prisma-binding.

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!

from prisma-binding.

@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.

from prisma-binding.