https://www.prisma.io/ logo
Join Slack
Powered by
Hey all :slightly_smiling_face: Our team badly n...
# orm-help
h
Hey all 🙂 Our team badly needs help with the problem I describe here: https://www.prisma.io/forum/t/how-to-handle-info-in-an-app-schema-with-additional-datatypes-than-db-schema/3800 TL;DR - If we have an app schema with types that are not present in the DB schema, how do we use the 
info
object in our resolvers? We can’t pass it on unmodified, as the AST would not match the DB schema. I can’t find any examples or documentation about it, and it seems to me to be a main component of Prisma that the app schema and DB schema are separated and can evolve separately, so there must be some better way than to do string manipulation, right?
a
not a complete solution, but maybe it's possible to use something like https://github.com/jakepusateri/graphql-list-fields to get a handle on the fields and strip out the ones you don't want
h
Hey Avi, thanks for chiming in 🙂 And sure, but that’s still resorting to string manipulation of the AST. I’m hoping there’s a better way
a
how would you imagine a solution for something like this looking?
h
In my naïve mind, I would hope that GraphQL/Prisma would be able to translate the 
info
object automatically between the app and DB layer.
a
meaning that the prisma-binding should be context aware, drop out any fields not in the prisma schema?
h
I’m not sure if that would solve it. 
prisma-bindings
correctly generates the DB schema and 
.ts
definitions, the problem is that the 
info
object that gets passed along won’t be understood by Prisma, seeing as the DB schema won’t know of those datatypes that only exist in the app schema.
As such, given the architecture of an app and db schema, 
prisma-bindings
excel if it is the DB schema that has extra types, and the app schema is only a subset of the DB. However, if types like our 
Boundary
type only exist in the app schema, we run into this issue, and I think this might become a more general problem in time as other projects come up with use cases for an app schema that contains types the DB does not
a
true, but the typings are only queries, mutations and variables, but there is no typings for the "query" itself (the fields you want returned), so it's not a question about typings i'm thinking though that when you pass an AST to a binding, it should be able to strip out any fields that don't belong to that schema. I think if something like this could be implemented in graphql-binding, it could solve this issue
h
It might 😄
As I mentioned in the forum post, in our case, it should be able to translate:
Copy code
{
  user {
    group { // group has a boundary
      value {
        name { // name has a boundary
          value
        }
      }
    }
  }
}
into
Copy code
{
  user {
    group {
      name
    }
  }
}
because the 
Boundary
adds the
Copy code
canView: Boolean!
  message: String!
  value: String
wrapper object around the DB types (or in this case, the scalar type 
String
. If instead of 
StringBoundary
it was i.e. 
UserBoundary
, the 
value
field would be of type 
User
)
Open in Slack
PreviousNext
Powered by