Creating related objects

This may not be an issue. I might just not know what I’m doing.

I’m using Slash and my schema includes:

type Workspace {
  id: ID!
  name: String!
  users: [User!]! @hasInverse(field: workspaces)
}

type User {
  username: String! @id @search(by: [hash])
  workspaces: [Workspace!]! @hasInverse(field: users)
}

Which I believe means in order to create a User, I also need to create a Workspace along with it (this is what I want; no User should be without a Workspace). Yet, when I send the following mutation…

mutation addUser($user: AddUserInput!) {
  addUser(input: [$user]) {
    user {
      username
      workspaces {
        id
      }
    }
  }
}

…with the following variables…

{
  "user": {
    "username": "test@gmail.com",
    "workspaces": [
      {
      	"name": "default"
    	}
    ]
  }
}

I get the following response…

  "data": {
    "addUser": {
      "user": [
        {
          "username": "test@gmail.com",
          "workspaces": []
        }
      ]
    }
  }

Which doesn’t have any workspaces, or at least doesn’t return the ID for the Workspace if it was created that I need to use next. Not only do I appear not to have the Workspace I wanted, I didn’t think it would be possible to create a User without one, which it appears I have. Any suggestions on what I’m doing wrong?

Hey @ericmand

This is not true. ! means that the field can’t be null but it doesn’t say that it is required. For e.g. The input below is valid because workspaces are non-null (they are [] which is different from null).

{
  "user": {
    "username": "test@gmail.com",
    "workspaces": []
  }
}

Whereas inputs like { "workspaces": null } or { "workspaces": [null] } are invalid given the schema that you have.

We can look into providing this as a feature. I’ll discuss this with the team next week and have updates for you soon.


I get the following response…

  "data": {
    "addUser": {
      "user": [
        {
          "username": "test@gmail.com",
          "workspaces": []
        }
      ]
    }
  }

I tried to reproduce this on the latest master but couldn’t. This should not happen and you should get back the workspaces if you provided while creating a user. I’ll try to check this on the version of Dgraph deployed on Slash and get back to you with my findings.

Which editor are you using to make these requests @ericmand?

I was using the editor built into the Slash dashboard.

image

Oh, you know what- It is the auth rule. In an effort to simplify my schema for this post I took that out and then as I was pasting the screenshots I realized that was probably playing a role. Sure enough when I take that out I get an ID back. I assume I was always creating a workspace but the Auth rule was preventing it from giving me details of it on the response. I suppose that is working as intended.

2 Likes

That’s right. As you figured out the auth rule is excluding the workspace. If you supply a JWT with a custom claim for the user, then you would get back the workspaces that the user can see. Let us know if you face any other issues.