Related types are optional

[mvanlonden]

For models

class Category(models.Model):
    name = models.CharField(max_length=100)

    def __str__(self):
        return self.name


class Ingredient(models.Model):
    name = models.CharField(max_length=100)
    notes = models.TextField()
    category = models.ForeignKey(
        Category, related_name='ingredients', on_delete=models.CASCADE)

    def __str__(self):
        return self.name

and schema

class CategoryType(DjangoObjectType):
    class Meta:
        model = Category


class IngredientType(DjangoObjectType):
    class Meta:
        model = Ingredient


class Query(object):
    all_categories = graphene.List(CategoryType)
    all_ingredients = graphene.List(IngredientType)

    def resolve_all_categories(self, info, **kwargs):
        return Category.objects.all()

    def resolve_all_ingredients(self, info, **kwargs):
        return Ingredient.objects.select_related('category').all()

I'd expect category type to include ingredients: [IngredientType!], but instead I see ingredients: [IngredientType]. Why is IngredientType not required? If that relationship returns a queryset with count greater than 0, wouldn't that queryset always contain the model instance?

[maarcingebala]

True, if the data comes from a database relationship I think it would be safe to assume that single nodes in the list aren't null objects.

To change that you'd have to override every single list field in your type like this:

class CategoryType(DjangoObjectType):
    ingredients = graphene.List(graphene.NonNull(IngredientType))

We had a similar issue with connections, as the default ones result in optional edges of optional nodes. In our case, if a connection is empty it should return an empty list and otherwise a list of required items. To achieve that we implemented our own connection and edge type with with additional required=True and NonNulls:

https://github.com/mirumee/saleor/blob/f1526e233b57e3706985fdbe8cb74a9e399fdc67/saleor/graphql/core/connection.py#L6

Maybe something similar could be achieved for lists.

[mvanlonden]

Ok great! Thanks for reaffirming this assumption. I'll look into subclassing the types to more accurately reflect the the reality. I'm generating typescript types using https://github.com/apollographql/apollo-tooling#apollo-clientcodegen-output so accurate typings prevent unnecessary existence checking.