Apollo client and __typename #234

plmercereau · 2018-07-30T22:00:38Z

Hello Hasura team!
First of all, many thanks and congrats on the wonderful work you did to deliver his engine (and of course your platform!)
I am running a cluster on v0.15.34 and try to connect to the data graphql endpoint (running on graphql-engine then).
I cannot run a query with '__typename' in it, for example:

query Profile {
  profile {
    id
    first_name
    __typename
  }
}

it sends me back that I have no permission to access '__typename' column:

{
  "errors": [
    {
      "path": "$[0].args.columns[2]",
      "error": "no such column exists : \"__typename\"",
      "code": "permission-denied"
    }
  ]
}

I assume the use of __typename is not implemented, but this is a big problem to me, as the entire apollo case system relies on the use of this property...
Have I missed something? If not, any plan to add this into your product?
Once again, many thanks for this project, I dreamt of it and you are making it real!

The text was updated successfully, but these errors were encountered:

coco98 · 2018-07-31T07:20:00Z

@plmercereau thank you for your kind words ❤️

The graphql-engine version is a little behind on the platform. The standalone graphql-engine has full support with __typename. We're working on updating the platform with the latest graphql-engine and we should be able to land it in a few days!

In the meanwhile, if you're not big on the kubernetes style of deploying and managing your work I'd recommend switching to the standalone version of the graphql-engine, but in any-case, everything should be up to date on the platform soon :)

plmercereau · 2018-07-31T12:43:12Z

That is great news! I was actually wondering how to upgrade / know the version of graphql-engine that is embedded in the platform. Looking forward!
I'd rather wait for it instead of swapping to a standalone graphql-engine, as there are very interesting features, e.g. your auth microservice that works perfectly with a Vue microservice. Btw, I plan to share a template in the hub that integrates Vue, Apollo, Hasura auth and data MS, most likely in September as I will be out for the next 6 weeks.
Another technology I found in love with over the past weeks is jenkins-x. I am dreaming of taking advantage of both Hasura platform and gql engine, and jenkins-x CI/CD and their elegant way of generating environment on-the-fly GitOps mode.... Definitely above my skills to contribute, though.
Thanks for your prompt reply, and good luck with your products full of promises!

shahidhk · 2018-09-04T06:31:53Z

@plmercereau Hasura Platform v0.16.1 packs the latest release GraphQL Engine. Here is the guide to upgrade: https://docs.platform.hasura.io/0.15/platform/manual/migration-v0_16/index.html

Let me know if you have any questions.

plmercereau · 2018-09-08T09:56:54Z

Great! Thanks for this @shahidhk !

…1884)   ### Description   This PR adds a bash script and a serverless function to clean up the output of `pg_dump` so that it can be used as a migration file for Hasura. This can be later integrated with the CLI so that the cleanup is handled by CLI. ### Affected components  - Scripts ### Related Issues    #1861 ### Solution and Design   - A serverless function written in Go gets the SQL content though HTTP POST. - A set of pre-defined lines are removed from this SQL string. - SQL comments are removed using regex matching. - Postgres triggers created by Hasura for use with event triggers are removed with regex matching. - Empty newlines are removed by regex matching. - Resulting string is returned in the HTTP response. ### Steps to test and verify   ```bash curl --data-binary @filename.sql https://hasura-edit-pg-dump.now.sh > newfile.sql ``` ### Limitations, known bugs & workarounds  NA

### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components  - CLI ### Related Issues    Close #2724, Close #2254, ### Solution and Design   For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds   - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong

### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see hasura#2724 and hasura#2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components  - CLI ### Related Issues    Close hasura#2724, Close hasura#2254, ### Solution and Design   For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds   - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong

## Description   We don't have dependency reporting mechanism for `mssql_run_sql` API i.e when a database object (table, column etc.) is dropped through the API we should raise an exception if any dependencies (relationships, permissions etc.) with the database object exists in the metadata. This PR addresses the above mentioned problem by -> Integrating transaction to the API to rollback the SQL query execution if dependencies exists and exception is thrown -> Accepting `cascade` optional field in the API payload to drop the dependencies, if any -> Accepting `check_metadata_consistency` optional field to bypass (if value set to `false`) the dependency check ### Related Issues   Close #1853 ### Solution and Design   The design/solution follows the `run_sql` API implementation for Postgres backend. ### Steps to test and verify  - Create author - article tables and track them - Defined object and array relationships - Try to drop the article table without cascade or cascade set to `false` - The server should raise the relationship dependency exists exception ## 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) PR-URL: hasura/graphql-engine-mono#2636 GitOrigin-RevId: 0ab1522

…te schema docs  ## Description ✍️   Included steps on how to create a user role and then restrict the user's access on certain fields on a remote schema. Page edited: [Remote schema permissions](https://hasura.io/docs/latest/graphql/core/remote-schemas/auth/remote-schema-permissions.html) ### Related Issues ✍ [#1047](hasura/graphql-engine-mono#1047)   ### Steps to test and verify ✍  View the deployed preview page [here](https://deploy-preview-3229--hasura-docs-mono.netlify.app/graphql/core/remote-schemas/auth/remote-schema-permissions.html#create-remote-schema-permissions). ## 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 ✍️  - ✅ Docs --- ### Kodiak commit message Information used by [Kodiak bot](https://kodiakhq.com/) while merging this PR. PR-URL: hasura/graphql-engine-mono#3229 Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com> GitOrigin-RevId: 7f963357afc129ba4553b270dbbc21a6f35066d6

## Description ✍️ Adds docs for the Prometheus Integration in cloud/EE. ### Related Issues ✍   [#2969](hasura/lux#2969) ### Solution and Design ✍  ### Steps to test and verify ✍  ### Limitations, known bugs & workarounds ✍  ## Changelog ✍️ - ✅ `no-changelog-required` ## Affected components ✍️  - ✅ Docs PR-URL: hasura/graphql-engine-mono#2869 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com> GitOrigin-RevId: b2ab087e4f2a484b4be0396cac51921e1ec87e28

…ra#234) GitOrigin-RevId: 318e07510ce693d29379cb0c402f404439c5b593

shahidhk closed this as completed Sep 4, 2018

shahidhk pushed a commit to shahidhk/graphql-engine that referenced this issue Sep 11, 2018

Fixes hasura#234

8cd3d66

hgiasac pushed a commit to hgiasac/graphql-engine that referenced this issue Dec 19, 2023

fix: proper handling command response in remote joins execution (hasu…

dd05d81

…ra#234) GitOrigin-RevId: 318e07510ce693d29379cb0c402f404439c5b593

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Apollo client and __typename #234

Apollo client and __typename #234

plmercereau commented Jul 30, 2018 •

edited

Loading

coco98 commented Jul 31, 2018

plmercereau commented Jul 31, 2018 •

edited

Loading

shahidhk commented Sep 4, 2018

plmercereau commented Sep 8, 2018

Apollo client and __typename #234

Apollo client and __typename #234

Comments

plmercereau commented Jul 30, 2018 • edited Loading

coco98 commented Jul 31, 2018

plmercereau commented Jul 31, 2018 • edited Loading

shahidhk commented Sep 4, 2018

plmercereau commented Sep 8, 2018

plmercereau commented Jul 30, 2018 •

edited

Loading

plmercereau commented Jul 31, 2018 •

edited

Loading