Schema created by Graphql is not accessible when making graphql+- calls and vice versa

Users Dgraph
,
1

Hi,

So lets take any schema a simple User

  1. Create schema using graphql schema.
  2. Now add some data.
  3. Query the data using grpc/ graphql± query using has or uid or any function.
  4. No results are returned.

Reverse the mechanism.

  1. Create schema using graphql± schema.
  2. Now add some data.
  3. Query the data graphql query using uid or filter function.
  4. No results are returned.

Now, if you created schema using graphql then it can only be queried by graphql or vice verse.

Why is that the case ? Given at graph level they are both represented exactly the same way. Is this by design or a bug ?

Regards
Harshad

2

When using a graphql schema, the predicates in DQL change to a dotted notation.

If a type Users has username edge then the predicate would be User.username

The only predicate that does not change is the uid. That is still available. And User.id is not available

1 Like
3

I tried using that already and it appears that is also not working. I have tried multiple attempt . Including dropping entire schema and recreating it.

I would have hoped that either of two service usage would have a unified experience as since they are both essentially resulting the same under the hood.

4

Can you provide your schema?

They do. I use daily DQL & GQL to manage the same dataset. There is probably a small misunderstanding somewhere with how your schema translates to DQL from GQL. Do you use Interfaces? That throws another kink into the mix.

2 Likes
5

Yes, that’s right, you are able to query your graphql records back via the ± interface, but it requires the dot notation.

2 Likes
6

Take the following schema:

type User {
  username: String! @id
  isContact: Contact! @hasInverse(field: isUser)
  hasSettings: [UserSetting]
  isActive: Boolean
}

type Contact {
  id: ID!
  name: String!
  hasSettings: [ContactSetting]
  isUser: User
}

interface Setting {
  id: 
  name: String!
  type: SettingType
  value: String!
}

type ContactSetting implements Setting {
  forContact: Contact! @hasInverse(field: hasSettings)
}

type UserSetting implements Setting {
  forUser: User! @hasInverse(field: hasSettings)
}

enum SettingType {
  BOOLEAN
  STRING
  FLOAT
  INT
}

And make the following mutation:

mutation MyMutation {
  addUser(input: [
    {
      username: "amaster"
      isActive: true
      isContact: {
        name: "Anthony Master"
        hasSettings: [
          {
            name: "isAwesome"
            type: BOOLEAN
            value: "true"
          }
          {
            name: "favoriteColor"
            type: STRING
            value: "Blue"
          }
        ]
      }
      hasSettings: [{
        name: "netWorth"
        type: FLOAT
        value: "0.02"
      }]
    }
  ]) {
    numUids
    user {
      username
      hasSettings {
        id
        name
        type
        value
      }
      isContact {
        id
        name
        hasSettings {
          id
          name
          type
          value
        }
      }
    }
  }
}

Your would write the correlating DQL (GraphQL±) query as:

query {
  # The `Users` in the next line, could be most anything. We could even name it Contacts and it would still get the Users as that is the function.
  Users(func: type(User)) { # This could be uid(), eq(), or any other supported function
    uid # Still has a uid even though username used as xid with @id directive in graphql schema
    User.username
    User.isContact {
      uid # There is no Contact.id but rather it gets translated to uid under the hood by the graphql endpoint. This is true for any ID usage in the schema
      Contact.name
      Contact.hasSettings {
        uid
        ContactSetting.forContact { # fields from the implementation are dotted with the implementation type
          uid # This is redundant data, just wanted to show the implementation dotted notation above
        }
        Setting.name # fields from the interface keep the interface's dotted notation
        Setting.type
        Setting.value
      }
    }
    User.isActive
    User.hasSettings {
      uid
      UserSetting.forUser {
        uid
      }
      Setting.name # See comments above why this is Setting.name and not UserSetting.name
      Setting.type
      Setting.value
    }
  }
}
2 Likes