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

fix json/jsonb columns as String values in nested returning of a mutation (fix #3365) #3375

Merged

Conversation

rakeshkky
Copy link
Member

@rakeshkky rakeshkky commented Nov 18, 2019

Description

PR #3198 caused the JSON/JSONB values returning as Strings when a mutation is performed with returning nested fields.
query:-

mutation {
  delete_author(where: {id: {_eq: 3}}){
    affected_rows
    returning{
      id
      name
      info
      articles{
        id
        title
        content
      }
    }
  }
}

Response:-

{
  "data": {
    "delete_author": {
      "affected_rows": 1,
      "returning": [
        {
          "id": 3,
          "name": "Author 3",
          "info": "{\"age\": 23}",
          "articles": []
        }
      ]
    }
  }
}

This PR fixes the same.

Affected components

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

Related Issues

Fix #3365

Solution and Design

The parsePGScalarValue is used to parse the Postgres column values correctly. The change in #3198 is made to select the mutated columns as Text values except for geometry/geography types. JSON/JSONB column values are parsed as JSON Strings and not as Postgres literals, which gives those values as Strings. A special parseJSONStringAsLiteral function is introduced, which forces all String values as Postgres literals.

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

Steps to test and verify

Reproduce #3365, the json/jsonb columns shouldn't be returned as strings.

Limitations, known bugs & workarounds

@netlify
Copy link

netlify bot commented Nov 18, 2019

Deploy preview for hasura-docs ready!

Built with commit cab14f0

https://deploy-preview-3375--hasura-docs.netlify.com

@hasura-bot
Copy link
Contributor

Review app for commit e8fa447 deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-e8fa447e

@rakeshkky rakeshkky force-pushed the issue-3365-json-returning-mutation branch from e8fa447 to 40315d2 Compare November 19, 2019 06:26
@hasura-bot
Copy link
Contributor

Review app for commit 40315d2 deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-40315d28

@rakeshkky rakeshkky force-pushed the issue-3365-json-returning-mutation branch from 40315d2 to ac1c5c9 Compare November 19, 2019 06:44
@hasura-bot
Copy link
Contributor

Review app for commit ac1c5c9 deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-ac1c5c9c

@rakeshkky rakeshkky force-pushed the issue-3365-json-returning-mutation branch from ac1c5c9 to 541da03 Compare November 19, 2019 08:17
@rakeshkky rakeshkky force-pushed the issue-3365-json-returning-mutation branch from 541da03 to 3117edd Compare November 19, 2019 08:20
@hasura-bot
Copy link
Contributor

Review app for commit 3117edd deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-3117eddc

@rakeshkky rakeshkky changed the title fix json/jsonb column values as Text in nested returning (fix #3365) fix json/jsonb column values returned as Strings in nested returning of a mutation (fix #3365) Nov 19, 2019
@hasura-bot
Copy link
Contributor

Review app for commit 58b4a0a deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-58b4a0ab

@rakeshkky rakeshkky added the c/server Related to server label Nov 19, 2019
@rakeshkky rakeshkky marked this pull request as ready for review November 19, 2019 10:02
@rakeshkky rakeshkky changed the title fix json/jsonb column values returned as Strings in nested returning of a mutation (fix #3365) fix json/jsonb columns as String values in nested returning of a mutation (fix #3365) Nov 19, 2019
mkSelCTEFromColVals qt allCols colVals =
=> (PGColumnType -> Value -> m (WithScalarType PGScalarValue))
-> QualifiedTable -> [PGColumnInfo] -> [ColVals] -> m S.CTE
mkSelCTEFromColVals parseFn qt allCols colVals =
Copy link
Contributor

Choose a reason for hiding this comment

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

Just for my own understanding: could you explain to me from a high-level what this function is doing? When I was first looking through this diff, I was slightly confused, because it seems like we’re parsing the values (using parseFn) but then immediately re-encoding them (using toTxtValue). It seems like mutateAndSel is doing that as part of some kind of two-pass query strategy, but it’s not quite clicking for me what the reason for doing that is.

Copy link
Member Author

@rakeshkky rakeshkky Nov 19, 2019

Choose a reason for hiding this comment

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

To be honest, this diff is not so informative. I'll give you a bit of context.

toTxtValue will encode any PGScalarValue to literal values. I thought it is enough and went for #3198. In case of json/jsonb values, the json string we're getting, let's say some String t where t is json string, is parsed into PGScalarValue as PGValJSON (String t). The toTxtValue converts PGValJSON (String t) to json encoding of a string value. The {"age": 23} is converted to something like "{\"age\": 23}" which is causing the bug. In mutateAndSel function, I'm enforcing all String t to PGValText t irrespective of what type it is, hence toTxtValue encodes correctly for json/jsonb values.

I hope you understand the above explanation. I'm happy to know any improvements to the current fix.

Copy link
Contributor

Choose a reason for hiding this comment

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

That definitely is helpful, so thank you for that explanation, but it actually doesn’t answer my original question (which is only semi-related to this pull request). Specifically, I’m trying to understand what mkSelCTEFromColVals is doing in the first place, from a high level. 🙂 Sorry if I didn’t make that very clear!

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay 🙂 . The mkSelCTEFromColVals will generate a SELECT query, that is used inside a WITH .... statement. The SELECT statement look like

SELECT * FROM VALUES ((col1-val, col2-val, col3-val), .....) AS "table_name" (col1, col2, col3)

The parseFn converts JSON value to col-val.

Copy link
Contributor

Choose a reason for hiding this comment

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

I probably should have been more clear: I can mostly make out what it does, but what I’m less sure about is why. If mutateAndFetchCols does the actual mutation query, and it returns a bunch of values, why don’t we parse them directly from that result? Why do we send them back through Postgres another time?

Copy link
Member Author

Choose a reason for hiding this comment

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

The (1) is possible only if we have the context of array types which #2243 is meant to solve. I think this PR is solving (2). We're fetching column values as Strings (except for geometry/geography types) and storing them as PGValText. The parseJSONStringAsLiteral is doing the job.

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 this PR is solving (2). We're fetching column values as Strings (except for geometry/geography types) and storing them as PGValText. The parseJSONStringAsLiteral is doing the job.

Okay, I think that helps me to understand better what’s going on. A followup question: why are we treating the geometry/geography types differently? They have a textual representation as well, right? So it seems as though we ought to be able to treat everything uniformly.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, we can use the textual representation for geometry/geography columns. Ideally, the returned columns are HashMap PGCol Text. I'll make the necessary change in next commit.

Copy link
Member Author

Choose a reason for hiding this comment

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

Now geometry/geography values are stored as Strings via 0f484df. Please approve if everything is OK. 🙂

Copy link
Member Author

Choose a reason for hiding this comment

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

@lexi-lambda Updated the PR with the latest master. Please review. 🙂

@hasura-bot
Copy link
Contributor

Review app for commit fdb6852 deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-fdb6852c

@hasura-bot
Copy link
Contributor

Review app for commit 281e5df deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-281e5df3

@hasura-bot
Copy link
Contributor

Review app for commit 340b63f deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-340b63fe

@hasura-bot
Copy link
Contributor

Review app for commit 980ddac deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-980ddacd

@hasura-bot
Copy link
Contributor

Review app for commit 60da288 deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-60da288c

Copy link
Contributor

@lexi-lambda lexi-lambda left a comment

Choose a reason for hiding this comment

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

Sorry for the long delay on getting this merged!

@hasura-bot
Copy link
Contributor

Review app for commit cab14f0 deployed to Heroku: https://hge-ci-pull-3375.herokuapp.com
Docker image for server: hasura/graphql-engine:pull3375-cab14f00

@lexi-lambda lexi-lambda merged commit 60acf7c into hasura:master Dec 10, 2019
@hasura-bot
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c/server Related to server
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Append Mutation Returning JSONB as String
3 participants