Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support of INPUT_FIELD_DEFINITION location #6

Open
FluorescentHallucinogen opened this issue Jan 31, 2019 · 5 comments
Open

Add support of INPUT_FIELD_DEFINITION location #6

FluorescentHallucinogen opened this issue Jan 31, 2019 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@FluorescentHallucinogen
Copy link
Contributor

Currently, @constraint supports only ARGUMENT_DEFINITION directive location.

Problem: e.g. Prisma extracts all query/mutation arguments to separate input types when generates schema from datamodel.

Please add support of INPUT_FIELD_DEFINITION location to be able to apply @constraint to input type fields. E.g.:

type User {
  name: String
  phone: String
  email: String
  ...
}

...

type Mutation {
  createUser(data: UserCreateInput!): User!
  updateUser(data: UserUpdateInput!, where: UserWhereUniqueInput!): User!
  deleteUser(where: UserWhereUniqueInput!): User
  ...
}

...

input UserUpdateInput {
  name: String
  phone: String
  email: String @constraint(format:"email")
  ...
}
@vsimko vsimko self-assigned this Jan 31, 2019
@vsimko vsimko added the enhancement New feature or request label Jan 31, 2019
@ecker00
Copy link

ecker00 commented Mar 14, 2019

Is this working as it was merged? I've tested a bit on v3.2.2, but still don't see any effect when using it on an input.

@FluorescentHallucinogen
Copy link
Contributor Author

@ecker00

Is this working as it was merged?

It seems you have confused. PR #4 was merged, but it fixes a completely different issue. Currently there is no PR that adds support of INPUT_FIELD_DEFINITION location.

BTW, pull requests are welcome. 😉

@FluorescentHallucinogen
Copy link
Contributor Author

Looks like objects validation rules proposed in #13 can solve the problem of input type fields validation. Moreover, objects validation approach opens up more possibilities like compounded validation: checking the value of multiple fields at the same time. It seems this can't be covered using the INPUT_FIELD_DEFINITION approach. @vsimko Please correct me if I'm wrong.

@hashinclude72
Copy link

please fix this, still no update ..... or if there will no updates could you tell me ay other package for Lambda

@vsimko
Copy link
Owner

vsimko commented Feb 3, 2020

Unfortunately, I don't have enough time to work on this package at the moment.
Is there anybody that would like to contribute ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants