Account for nested models and Dates/Times

[spockNinja]

@patrick91

Thanks for all the work in getting Serializers working with graphene-django. I whipped up a few additions after testing out your PR on a project. The biggest things I noticed when testing were the ability to nest models in serializers and the correct mapping for Date/Time fields.

Let me know if there's anything I can do to help get this feature merged upstream.

[patrick91]

@spockNinja thank you for this, looks good.

Can you add some tests for the types and the nested model?

[spockNinja]

Absolutely. 👍

[spockNinja]

@patrick91

I got to the point where I was using the graphql endpoint in our client-side, and realized that the response from the mutation is less flexible than what we had before.

Much like the root flexibility of graphql, we have it so that a mutation should be able to choose what data it wants back, at least data related to the mutated object.

In our case, it looks like this:

mutation ($createPolicyInput: CreatePolicySerializerInput!) {
  createPolicy(input: $createPolicyInput) {
    policy {
      id
      number
    }
  }
}

And the policy fields can be anything that would normally come from a policy query.

Before the serialization mapping, it looked like this:

class CreatePolicy(graphene.Mutation):
    class Input:
        new_policy_data = graphene.Argument(NewPolicyData)

    policy = graphene.Field(Policy)

    @staticmethod
    def mutate(root, args, context, info):
        new_policy_data = args.get('new_policy_data')
        effective_date = new_policy_data.get('effective_date')
        expiration_date = new_policy_data.get('expiration_date')
        line_id = new_policy_data.get('line_id')
        line = Line.objects.get(id=line_id)
        policy = create_policy(effective_date, expiration_date, line)
        return CreatePolicy(policy=policy)

To achieve similar functionality as easily with the serializer mapping, it has to be to a ModelSerializer and not just a BaseSerializer. So I tried my hand at a ModelSerializerMutation class that is working for me. fc521b1

With that, it now looks like:

class CreatePolicy(ModelSerializerMutation):

    class Meta:
        serializer_class = CreatePolicySerializer

The question is, do you think others would want this? If so, I'll clean it up and probably pull some commonalities between it and the SerializerMutation. If not, I'll just make it a part of our own core graphql library.

[patrick91]

@spockNinja sorry for the late reply I was at europython :)

So, I'm not really sure that's a common use case, when I create a Policy I'd expect to get its fields right away, instead of having them namespaced into policy, no?

Maybe after my PR is merged we can create a discussion on the main repo and see what other people think :)

[spockNinja]

No problemo. I'm sure that was a good time. :)

I pulled that last bit out for now, and added tests for the nested serializers and date/time converters.

[patrick91]

Great stuff, sorry it took me a while to get back to you!