No input field null validation on non nullable fields

[jdgamble555 (Jonathan Gamble)]

@MichelDiz

Pay attention that a Query and a Mutation are totally different things. So both have their own specs. In Dgraph we have this distinction too, only Upsert Block you can do some tricks outside of it. But in a mutation, you can only use RDF or JSON, never a DQL(like cascade directive) functions.

Correct. Because, the specs do not talk about mutations, just queries (when I said you were right).

@MichelDiz

I’ll ping some one about this. Does it has a ticket? I think you have some open tickets right?

No one ever responds to my feature requests one way or the other, so I have no idea if there is an open ticket. Should there be? @amaster507 mentioned this update-after problem a long time ago. I do feel like this is more of an overlooked problem then a feature request:

Feature Request: Update After @auth Validation

Experience Report for Feature Request What you wanted to do Prevent a user from updating certain fields based on @auth rules for validations, the same way I can prevent a user from adding certain fields based on @auth rules for validations. What you actually did I can currently prevent a user from adding a certain value to the database by using many different types of field validation @auth rules: By using some rules like this: type Language @withSubscription @auth( add: { rule: "query…

As I stated in my post, the code (in go) to validate both frontend and backend is already written. It just needs to be connected to a new method: update-after. This opens up a world of backend validation possibilities that frontend developers will love.

@MichelDiz

So, if GraphQL spec doesn’t cover it. We could potentially transpose the code(from graphql-non-null-directive) or do something similar in go and introduce it into the Dgraph core. So the directive would be native.

Should I create a new feature request thread for that?

Thanks,

J