Custom Directive Issue (Documentation Related)

Users GraphQL
1

https://graphql.dgraph.io/doc/custom/query

The “getTwitterUser” query definition go into schema.graphql, but the schema update fails with:
{"errors":[{"message":"resolving updateGQLSchema failed because input:36: getTwitterUser is a reserved word, so you can't declare a query with this name. Pick a different name for the query.\n (Locations: [{Line: 3, Column: 4}])","extensions":{"code":"Error"}}]}

The schema update works after updating changing the name “getTwitterUser” to something not already reserved in dgraph. Please note, the query from client should reflect the updated name to get the underlying custom directive activated.

1 Like
2

same is true for the following Mutations:

type Mutation {
  addTwitterUser: TwitterUser @custom(http:{
    url: "http://mydomain.com/api"
    method: "GET"
  })
  updateTwitterUser: TwitterUser @custom(http:{
    url: "http://mydomain.com/api"
    method: "GET"
  })
  deleteTwitterUser: TwitterUser @custom(http:{
    url: "http://mydomain.com/api"
    method: "GET"
  })
}

There needs to be a check on the reserved words that if the type has the @remote directive then the get* and query* queries are not reserved and the add*, update*, and delete* mutations are not reserved

2 Likes
3

Good point here @amaster507. We’ll add a fix for this to master in a couple of days.

1 Like
4

Just a thought: we might also want to consider the “override” concept. This will help preserve the natural form of the original schema and reduce interpretation bloat.

5

Could you give an example of this?

6

For example, getTwitterUserCustom “overrides” the default getTwitterUser. When the client calls getTwitterUser, it sees that the default has been overridden and hits the custom directive. Clients do not need to know before hand the name of a specific custom function and this behavior is provisioned in a generic manner.

7

@anand Default functions are well defined in graphql and depends on type name given by users. So graphql client will know about them. The idea of the custom directive is to give user flexiblity to change inbuilt structures of graphql and if user gives any custom name then he wants to use them instead of inbuilt ones.

8

Hi @JatinDevDG, thinking from the application side, the question is do we need the client to always choose a particular behavior. In certain situations, such as say a adding a system timestamp via a directive for a payment transaction, we may not want the user to ever have the option of choosing alternate behaviors on mutation. Imagine if we have multiple such directives enforcing mandatory behaviors, the client will need to check/ask and this can slow down development speed.

9

yeah, actually this can happen in certain use case and we will definitely look into that. But the idea of custom directive is to let app developers choose their query/mutations and modify/add whatever they want. May be in some use case developers wants to use only certain functions and not the inbuilt ones.

So to cover both cases we support inbuilt and custom (you can say user defined) functions or structures and it adds lots of flexibility into the design.
And the developers only uses those custom functions then i guess it’s not big problem for them to know what function they defined and to use it.
But thanks for suggestion and we will look for use case where this can create problem and work on it.

10

Sure @JatinDevDG , thanks for considering it.

1 Like