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

Server: Don't throw validation error while creating remote relationship joining singular type with array type #5603

Merged

Conversation

codingkarthik
Copy link
Contributor

@codingkarthik codingkarthik commented Aug 17, 2020

Closes #5133

The issue arises when the user tries to make a remote relationship type, joining a singleton type with an array type. For example, joining Int with [Int].

Description

Changelog

  • CHANGELOG.md is updated with user-facing content relevant to this PR. If no changelog is required, then add the no-changelog-required label.

Affected components

  • Server
  • Console
  • CLI
  • Docs
  • Community Content
  • Build System
  • Tests
  • Other (list it)

Related Issues

Solution and Design

Steps to test and verify

Limitations, known bugs & workarounds

Server checklist

Catalog upgrade

Does this PR change Hasura Catalog version?

  • No
  • Yes
    • Updated docs with SQL for downgrading the catalog

Metadata

Does this PR add a new Metadata feature?

  • No
  • Yes
    • Does run_sql auto manages the new metadata through schema diffing?
      • Yes
      • Not required
    • Does run_sql auto manages the definitions of metadata on renaming?
      • Yes
      • Not required
    • Does export_metadata/replace_metadata supports the new metadata added?
      • Yes
      • Not required

GraphQL

  • No new GraphQL schema is generated
  • New GraphQL schema is being generated:
    • New types and typenames are correlated

Breaking changes

  • No Breaking changes

  • There are breaking changes:

    1. Metadata API

      Existing query types:

      • Modify args payload which is not backward compatible
      • Behavioural change of the API
      • Change in response JSON schema
      • Change in error code
    2. GraphQL API

      Schema Generation:

      • Change in any NamedType
      • Change in table field names

      Schema Resolve:-

      • Change in treatment of null value for any input fields
    3. Logging

      • Log JSON schema has changed
      • Log type names have changed

@hasura-bot
Copy link
Contributor

Review app for commit 22b4b28 deployed to Heroku: https://hge-ci-pull-5603.herokuapp.com
Docker image for server: hasura/graphql-engine:pull5603-22b4b285

CHANGELOG.md Outdated
@@ -21,6 +21,7 @@ If you do have such headers configured, then you must update the header configur
- server: add logs for action handlers
- server: add request/response sizes in event triggers (and scheduled trigger) logs (#5463)
- server: change startup log kind `db_migrate` to `catalog_migrate` (#5531)
- server: don't throw validation error when creating remote relationships joining singleton type with array type with same base type (fixes #5133)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this really close 5133? I don't see any mention of list types there..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does. The issue doesn't mention anything about the list type, because the error message thrown is incorrect. Ideally, the error message should have been

Error remote relationship: cannot validate remote relationship because expected type \"[Int]\" but got \"Int\"

instead of

Error remote relationship: cannot validate remote relationship because expected type \"Int\" but got \"Int\"

The reason the list notation is omitted from the error message because of this line

This PR solves that issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error message can occur in another case too, while joining an [Int] type to a Int type, where the validation is justified but the error message will be the same

Error remote relationship: cannot validate remote relationship because expected type \"Int\" but got \"Int\"

which is not very helpful.

I'll fix the error message.

else (when
(getBaseTy actualType /= getBaseTy expectedType)
(Failure (pure $ ExpectedTypeButGot expectedType actualType)))
-- The GraphQL spec says that, we can coerce a singleton value into an array
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is great. While you are here can you give assertType a better name? I guess what we're actually doing here is asserting that actualType is coercible to expectedType?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, is this deficient in other ways according to the spec?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess what we're actually doing here is asserting that actualType is coercible to expectedType?

Yes, that's what we're doing. But I'm not sure, what can be a better name here? Perhaps, isTypeCoercible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, is this deficient in other ways according to the spec?

Yes, it was. My patch would have allowed to make a remote relationship joining types [[Int]] and [[[Int]]], which is illegal, as specified in the GraphQL spec.

I have fixed this in the next commit

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isTypeCoercible sounds good to me!

@netlify
Copy link

netlify bot commented Aug 19, 2020

Deploy preview for hasura-docs ready!

Built with commit a34913f

https://deploy-preview-5603--hasura-docs.netlify.app

@hasura-bot
Copy link
Contributor

Review app for commit 32766d2 deployed to Heroku: https://hge-ci-pull-5603.herokuapp.com
Docker image for server: hasura/graphql-engine:pull5603-32766d2e

@hasura-bot
Copy link
Contributor

Review app for commit 0a34d58 deployed to Heroku: https://hge-ci-pull-5603.herokuapp.com
Docker image for server: hasura/graphql-engine:pull5603-0a34d58d

CHANGELOG.md Outdated Show resolved Hide resolved
Co-authored-by: Tirumarai Selvan <tiru@hasura.io>
pure ()
isTypeCoercible :: G.GType -> G.GType -> Validation (NonEmpty ValidationError) ()
isTypeCoercible actualType expectedType =
-- The GraphQL spec says that, a singleton type can be coerced into an array
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think technically "singleton" type is called named type but we can fix this comment later.

CHANGELOG.md Outdated
@@ -21,6 +21,7 @@ If you do have such headers configured, then you must update the header configur
- server: add logs for action handlers
- server: add request/response sizes in event triggers (and scheduled trigger) logs (#5463)
- server: change startup log kind `db_migrate` to `catalog_migrate` (#5531)
- server: allow remote relationships joining `type` column with `[type]` input argument as spec allows this coercion (fixes #5133)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, can you push this to Next release section also?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

@hasura-bot
Copy link
Contributor

Review app for commit a3704b4 deployed to Heroku: https://hge-ci-pull-5603.herokuapp.com
Docker image for server: hasura/graphql-engine:pull5603-a3704b4c

@codingkarthik codingkarthik added the s/do-not-merge Do not merge this pull request to master label Aug 21, 2020
else Failure (pure $ ExpectedTypeButGot expectedType actualType)
-- we cannot coerce two types with different nesting levels,
-- for example, we cannot coerce [Int] to [[Int]]
else Failure (pure $ ExpectedTypeButGot expectedType actualType)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we simplify this code by using MultiwayIf

if | actualBaseType /= expectedBaseType -> raiseValidationError
   | actualNestingLevel /= expectedNestingLevel && actualNestingLevel /= 0 -> raiseValidationError
   | otherwise -> pure ()
   where
     raiseValidationError = Failure $ pure $ ExpectedTypeButGot expectedType actualType

Of course with appropriate comments.

@hasura-bot
Copy link
Contributor

Review app for commit d4e2955 deployed to Heroku: https://hge-ci-pull-5603.herokuapp.com
Docker image for server: hasura/graphql-engine:pull5603-d4e2955e

@hasura-bot
Copy link
Contributor

Review app for commit 22d563c deployed to Heroku: https://hge-ci-pull-5603.herokuapp.com
Docker image for server: hasura/graphql-engine:pull5603-22d563c3

@codingkarthik codingkarthik removed the s/do-not-merge Do not merge this pull request to master label Aug 26, 2020
@hasura-bot
Copy link
Contributor

Review app for commit 95b0808 deployed to Heroku: https://hge-ci-pull-5603.herokuapp.com
Docker image for server: hasura/graphql-engine:pull5603-95b08086

@kodiakhq kodiakhq bot merged commit 15794ad into hasura:master Aug 27, 2020
@hasura-bot
Copy link
Contributor

Review app https://hge-ci-pull-5603.herokuapp.com is deleted

@tirumaraiselvan tirumaraiselvan added this to the v1.3.3 milestone Nov 3, 2020
codingkarthik pushed a commit to codingkarthik/graphql-engine that referenced this pull request Nov 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants