这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@wawhal
Copy link
Contributor

@wawhal wawhal commented Jan 8, 2019

Description

What component does this PR affect?

  • Server
  • Console
  • CLI
  • Docs
  • Community Content
  • Build System

Requires changes from other components? If yes, please mark the components:

  • Server
  • Console
  • CLI
  • Docs
  • Community Content
  • Build System

Related Issue

Solution and Design

Type

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Docs update
  • Community content

Checklist:

  • I have read the contributing guide and my code conforms to the guidelines.
  • This change requires a change in the documentation.
  • I have updated the documentation accordingly.
  • I have added required tests.

@wawhal wawhal requested a review from rikinsk-zz January 8, 2019 08:18
@hasura-bot
Copy link
Contributor

Review app for commit 6113f66 deployed to Heroku: https://hge-ci-pull-1341.herokuapp.com
Docker image for server: hasura/graphql-engine:pull1341-6113f66

@rikinsk-zz rikinsk-zz merged commit a9e2326 into hasura:master Jan 8, 2019
@hasura-bot
Copy link
Contributor

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

@Ardhimas
Copy link

Ardhimas commented Jan 8, 2019

@wawhal Do you mind explaining why this example was removed? Does it not work anymore?

@sivadass
Copy link

@wawhal Do you mind explaining why this example was removed? Does it not work anymore?

Yeah i also want to know?

@wawhal
Copy link
Contributor Author

wawhal commented Jan 23, 2019

@Ardhimas @sivadass it did work.
But if you are making a lot of repeated requests, as in the case of polling, you will end up reaching the rate limits of auth0's authentication API. We therefore currently recommend that you use JWT with Hasura.

Is there any particular reason why you folks prefer the webhook flow over JWT?

hasura-bot pushed a commit that referenced this pull request Nov 13, 2024
…ker compose engine metadata (#1341)

### What
This PR does three related things:
* Adds an execution test that tests that nested relationships work in
field selection in Postgres (taken from #935)
* Refactors the way capabilities are handled in metadata resolve to
account for difference between NDC 0.1.x and 0.2.x. Specifically, NDC
0.1.x connectors are assumed to support nested relationships in field
selection, but do not support them in filtering and ordering. Whereas in
NDC 0.2.x, a capability exists to indicate nested relationship support,
but then you must support them in filtering and ordering as well as
field selection.
* Updates the metadata used in the default docker compose so that it:
    * uses an up to date pg schema
    * uses BooleanExpressionType instead of ObjectBooleanExpression
    * removes commands that do not exist on the pg connector
* adds the Institutions model so that nested relationships can be tested

This PR does not add support for nested relationships in filtering or in
ordering. It also does not block nested relationships in field selection
for NDC 0.2.x connectors that do not support it. This will all come in
later PRs.

### How

In `metadata_resolve`, the resolved `DataConnector` used to contain a
copy of the `ndc_models::Capabilities`. This has been removed and
instead a `metadata_resolve` specific `DataConnectorCapabilities`
structure is used instead. This decouples `metadata_resolve` from
`ndc_models` and allows it to capture differences between NDC 0.1.x and
0.2.x properly.

There is now a specific function per NDC version that creates a
`DataConnectorCapabilities`. This removes the need for capabilities
migration code.

V3_GIT_ORIGIN_REV_ID: 0eb119aab0e5fa22977d84820025f75c6102036d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants