Mutations for related objects

[schroeer]

This is a request for comments and advice rather than a bug report.

I will use the example setup of this issue again.

I would like to be able to create a new person with new dogs at once, like so:

mutation NewPersonWithDogs($person: PersonWithDogsCreateInput!) {
  createPerson(input: [$person]) {
    id
    name
    dogs {
      name
    }
  }
}

$var = {
    person => {
        name => "Joe",
        dogs => [
            {
                name => "Betsy"	
            },
            {
                name => "Barkley"
            },
            {
                name => "Barney"
            }
        ]
    }
}

This works "out of the box", if I replace the schema created by GraphQL::Plugin::Convert::DBIC with the following:

type Person {
  dogs: [Dog]
  id: Int!
  name: String!
}
type Dog {
  id: Int!
  name: String!
  owner: Person!
}
type Query {
  people(id: [Int!]!): [Person]
}

input PersonWithDogsCreateInput {
  name: String!
  dogs: [PersonalDogCreateInput!]!
}
input PersonalDogCreateInput {
  name: String!
}
type Mutation {
  createPerson(input: [PersonWithDogsCreateInput!]!): [Person]
}

However, there are some limitations for doing this outside of GraphQL::Plugin::Convert::DBIC:

1. I see no easy way to amend the schema generated by GraphQL::Plugin::Convert::DBIC other than completely replacing it.

2. The mutation has to be named createPerson due to how the resolver determines the method and the source name. The name should better be taken from $info->{return_type}->name.

Do you think that such mutations are a good idea and should be included? Any other comments? Thank you!

[mohawk2]

Such mutations are an excellent idea! Being able to do one round-trip rather than N+1 is a benefit of GraphQL, and the nesting of input objects is the idiomatic way to do it. In DBIC terms, how would one identify the existence of such relationships? Because one could then automatically enable them in the generated schema.

Also, if you want to influence the shape of the generated schema, can you give concrete examples to guide my thinking? Would the above relationship-detecting not be enough?

[schroeer]

The relevant relation is DBIC's has_many(). A Person->has_many('dogs' => Dog). The dbicdump utility sets up this relation automatically (based on the foreign key in table dog).

However, a person might additionally have many cats and a dog may have many toys (apologies for the silly example). This shows that the matrix of potential create... mutations can get pretty large: createPersonWithDogs(), createPersonWithCats(), createPersonWithCatsWithDogsWithToys(), createDogWithToys(), etc.

In think that in most cases a user will not want all of these. Off the top of my head I see these options:

1. Make the schema generation configurable. I think this would be the best.

2. Do not provide any of these mutations automatically but allow the user to amend the schema to add them as needed. Plus make the default resolver support those user-supplied mutations. That's what I'll be doing for now. In my real use case I'll only need a few and only one level deep.

3. Provide only the "maximal" ones (createPersonWithCatsWithDogsWithToys(), createDogWithToys()) but allow that inputs are filled in incompletely so that e.g. the first mutation can be used to create only a person and their cats. This does not look very nice to me though.

type Mutation {
  createPersonWithCatsWithDogsWithToys(input: [PersonWithCatsWithDogsWithToysCreateInput!]!): [Person]
}
input PersonWithCatsWithDogsWithToysCreateInput {
  name: String!
  cats: [PersonalCatCreateInput]
  dogs: [PersonalDogWithToysCreateInput]
}
input PersonalCatCreateInput {
  name: String!
}
input PersonalDogWithToysCreateInput {
  name: String!
  toys: [PersonalToyCreateInput]
}
input PersonalToyCreateInput {
  color: String!
}

[mohawk2]

I don't see a problem with having:

input Person {
  name: String!
  cats: [CatCreateInput]
  dogs: [DogCreateInput]
}

Since the cats etc entries are nullable, then if you want to create a person with no cats, just give the person-relevant info? Am I missing something? I believe all I need to do is make the schema add these things, and the resolver to understand it? (probably would need to add the RecursiveUpdate helper, or whatever it's called)

[schroeer]

That's my number 3 with nicer names.

One thing to keep in mind is that in your example, DogCreateInput should not contain the owner field, because that will be set to the id of the new person.

The mutation createDog, however, needs the owner field and thus a different input.