Ref or Set expected, Object provided

Help
, , , ,
1

I am creating a todo app in which :

  • a user can have many todos

  • and a todo can have a single user or owner

my schema is :

enum Priority {
  P1
  P2
  P3
  P4
}

type User {
  name: String!
  email: String! @unique
  password: String!
  todos: [Todo!] @relation
}

input UserInput {
  name: String!
  email: String! @unique
  password: String!
  todos: UserTodosRelation
}

type Todo {
  todo: String!
  description: String!
  status: Boolean!
  date: String!
  priority: Priority
  uid: ID!
  subtodos: [Todo!]
  comments: [String!]
  reminders: [String!]
  owner: User!
}

input TodoInput {
  todo: String!
  description: String!
  status: Boolean!
  date: String!
  priority: Priority
  uid: ID!
  subtodos: [TodoInput!]
  comments: [String!]
  reminders: [String!]
  owner: TodoUserRelation
}

input UserTodosRelation {
  create: [TodoInput]
  connect: [ID]
  disconnect: [ID]
}

input TodoUserRelation {
  create: UserInput
  connect: ID
  disconnect: Boolean
}

type Query {
  allTodos: [Todo!]!
  findTodoByUid(uid: ID!): Todo!
  userExists(email: String!): Boolean! @resolver(name: "userExists")
  userByEmail(email: String!): User! @resolver(name: "userByEmail")
}

type Mutation {
  createSubTodo(parentId: ID!, newData: TodoInput!): Todo!
    @resolver(name: "create_sub_todo")
  updateRemindersList(todoUid: ID!, reminder: String!): String!
    @resolver(name: "updateRemindersList")
  deleteTodo(id: ID!, parentId: ID): Todo! @resolver(name: "deleteTodo")
}

now when I create a todo I want it to connect to a user using ID

my grapgql mutation :

mutation {
  createTodo(data: {
    todo: "test"
    description: ""
    status: false
    uid: "0.157486448458"
    priority: P4
    date: "2021-03-23T14:07:17.851Z"
    owner: {connect: 295406427520893447}
  }) {
    todo
    owner {
       name
      email
    }
  }
}

but it returns an error :

{
  "errors": [
    {
      "message": "Ref or Set expected, Object provided.",
      "extensions": {
        "code": "invalid argument"
      }
    }
  ]
}

I don’t know what is the problem and where I am going wrong.

2

Hi,

I’ve been working with your schema and have been able to reproduce the error you’re seeing. However modifying it by removing the input types solves the issue and allows for Users to be created or connected with Todos. I also removed the non-null from the sub-todos since not every todo item will have subs, presumably. So then your schema would look like:

enum Priority {
  P1
  P2
  P3
  P4
}

type User {
  name: String!
  email: String! @unique
  password: String!
  todos: [Todo] @relation
}

type Todo {
  todo: String!
  description: String!
  status: Boolean!
  date: String!
  priority: Priority
  uid: ID!
  subtodos: [Todo]
  comments: [String!]
  reminders: [String!]
  owner: User!
}

That allows for the following queries to complete:

mutation {
  createUser(data:{
  	name: "Alice Doe"
    email:"alice@doe.org"
    password:"password"
  }) {
    _id
    name
    todos {
      data{
        todo
      }
    }
  }
  }

mutation {
  createTodo(data: {
    todo: "Alice's first to-do item",
    description: "",
    status: false,
    uid: "0.157486448458",
    priority: P4,
    date: "2021-05-07T23:50:00.000Z",
    owner:{connect:297972770013184520}

  }) {
    _id
    todo
    owner{
      name
      email
    }

  }
}

(The user ID is from my Fauna, obviously yours will be different.)

Both of these queries complete successfully:

{
  "data": {
    "createUser": {
      "_id": "297972770013184520",
      "name": "Alice Doe",
      "todos": {
        "data": []
      }
    }
  }
}

{
  "data": {
    "createTodo": {
      "_id": "297972830699520525",
      "todo": "Alice's first to-do item",
      "owner": {
        "name": "Alice Doe",
        "email": "alice@doe.org"
      }
    }
  }
}

I’m not certain but I what think is happening here is that the multiple levels of field dependencies in your original schema aren’t getting resolved properly. I’d have to dig into the logs to know for sure, but the simpler schema should still accomplish the same goal.

Is there a business requirement behind having the input types included? If so that may change things.

Please let me know if this solves your problem or if you need additional assistance.

Cory