tirumaraiselvan / graphql-engine Goto Github PK

Currently, remote schema modify does a "Create and Delete" which means metadata inconsistencies are very strict e.g. you can't modify header if there is a remote relationship, etc

Currently only data key is looked for.

smoothen the experience when columns have a !

Currently we're using aeson's decode to parse into Value structures, lookup the data field, then union the HashMaps, which is convenient but less efficient than if we parsed the boundaries of the object using the attoparsec combinators, located the data key boundaries, and then just concatenated the bytestrings together at the right point as a Builder (the EncJSON uses this). Here is an example of parsing directly.

This came up here: hasura#2432

https://graphql.github.io/graphql-spec/June2018/#sec-Response-Format

The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value. This entry is reserved for implementors to extend the protocol however they see fit, and hence there are no additional restrictions on its contents.

It seems good to just union all of the extensions fields from remotes and (if any) from hasura. The only trouble obviously is when names overlap or the client needs to disambiguate extension responses from different remotes used in same query.

We could return our own extensions where we put remote extensions under separate namespaces. But that might entail rewriting clients which might defeat the purpose...

No-op file reorganization

We should allow to join with fields like:

 query {
    stripe (account_id : $account_id) {
            subscriptions(sub_id : $sub_id) {
                 leaf1
                 leaf2
             }
      }
}

This will involve changing the metadata API to something like:

type: create_remote_relationship
args:
  name: message
  table: profiles
  hasura_fields:
    - stripe_account_id
    - stripe_sub_id
  remote_schema: my-remote-schema
  remote_field: 
    stripe:
      arguments:
        account_id: "$stripe_account_id"  <- i specify this in the UI
        group: "$g"  <- i specify this in the UI
      field:
        subscriptions:
          arguments:
            sub_id: "$strip_sub_id"  <- i specify this
           -- sub_timestamp: <- result: i want this field
           -- sub_order <- result: and this

Log the batch query and the corresponding response for easy debugging.

Currently, query plan will cache the entire request. But after breaking the execution plan into sub-plans, it breaks the existing design. Currently, query plan caching is commented out in the PR.

The console generates the following query

{
  "type": "bulk",
  "args": [
    {
      "type": "create_remote_relationship",
      "args": {
        "name": "foo",
        .
        .
        "remote_field": {
          "hge_remote_addresses": {
            "arguments": {
              "where": {
                "_and": {
                  "id": {
                    "_eq": "$id"
                  },
                  "floor": {
                    "_eq": "$location_id"
                  }
                  .
                  .
}

The _and is generated as an object. It should be an array
This gives the following error

{
  "path": "$.args[0].args",
  "error": "ExpectedTypeButGot (TypeNamed (Nullability {unNullability = True}) (NamedType {unNamedType = Name {unName = \"String\"}})) (TypeNamed (Nullability {unNullability = True}) (NamedType {unNamedType = Name {unName = \"Int\"}})) :| []",
  "code": "remote-schema-error"
}

Change hashmap implementation to something which preserves the order of selection set.

Currently, the websocket code doesn't combine results if there are more than one top level fields. This results in few test failures.

For example, defining remote relationship like this fails

 remote_field:
    hge_remote_baseball_action_plays:
      arguments:
        where:
          _and:
          - baseball_event_state_id:
              _eq: $id
          - _not:
              baseball_event_state_id:
                _neq: $id

with error:

  "path": "$.args.remote_relationships[0]",
  "error": "UnsupportedMultipleElementLists :| []",
  "code": "remote-schema-error"

Remote arguments are able to validate scalar fields but not complex fields like List, Object etc

E.g.

type: create_remote_relationship
args:
  name: message
  table: profiles
  hasura_fields:
    - id
  remote_schema: my-remote-schema
  remote_field: messages
  remote_arguments:
    where:
      id:
        _eq: "$id"

Instead we can make this implicit and extract referenced fields from the remote_field section. Simplifies API and removes something extra to validate.

This also removes the weird question of whether including extraneous hasura fields that go unused should be a validation error.

For e.g. suppose we create a relationship with only static values, then no remote query is generated. If we add a hasura column in the API (but not use it in the join), then it works.

This is because of the function peelRemoteKeys here:

neededHasuraFields is actually an empty array and this is used here for creating a Batch:

Currently it is sequential. We have a tree of plans and as per the graphql spec, we can parallelize them.

Currently we cannot query interface types (in vanilla remote or as remote relationship).

Make sure the first hashmap is templatedArguments here: hasura@0f55e79

Repro:

query {
  profiles {
    name
    messageBasic {
      msg
    }
  }
}

We need to add 3 dependencies for Remote Relationship:

Table dependency: RemoteRel depends on the table
Column dependencies: All the Tables columns are also a dependency for the RemoteRel
Remote Schema dependency: RemoteRel depends on the remote schema

This query

    {
      profiles {
        id
        user_output_1: usersNestedArgs(where: {provider: {_eq: "provider1"}}) {
          id
          provider
        }
        user_output_2: usersNestedArgs(where: {_or: [{id: {_eq: 1}}, {provider: {_eq: "provider2"}}]}) {
          id
          provider
        }
        user_output_3: usersNestedArgs(where: {id: {_neq: 1}}) {
          id
          provider
        }
      }
    }

gave the following output

  data:
    profiles:
    - id: 1
      user_output_1: &user1
      - id: 1
        provider: provider1
      user_output_3: []
      user_output_2: *user1
    - id: 2
      user_output_1: []
      user_output_3: &user2
      - id: 2
        provider: provider2
      user_output_2: *user2
    - id: 3
      user_output_1: &user3
      - id: 3
        provider: provider1
      user_output_3: *user3
      user_output_2: []

User are facing issues in the join function.

I'm having issues with remote joins
Specifically no remote objects left for joining at
I can confirm the request is beign sent to my remote schema correctly, so it seems the issue is the handling of the response by hasura.

---

When using Remote joins, I get this error "message": "no remote objects left for joining at {"descriptionRich":"# F&C"}":thinking:

We do not have ENUM type which can be a hasura_field but an ENUM type might be used as a static value in the remote args.

Expressing an ENUM and parsing it as G.Value will require some custom logic.

Let us say in profiles table, role user does not have select permission on column id.
But id column is also used in defining a remote relationship user_remote. Currently the following query

{
  profiles {
    user_remote {
      username
    }
  }
}

gives error

errors:
- extensions:
    path: "$.selectionSet.profiles_by_pk"
    code: unexpected
  message: could not lookup "id" in 'profiles'

MessageWhereInpObj_for_remote_relationship may not be unique if there are two relationships using the same input type object.

https://discordapp.com/channels/407792526867693568/428469959530643466/592736027844804621