Graphene-django: Unable to subclass or emulate DjangoObjectType

[techdragon]

Subclassing DjangoObjectType so as to customise it for use in derived objects in the schema causes the execution of:

assert is_valid_django_model(model)

which fails the assertion due toclass MyNewClass(DjangoObjectType): not having a meta class, as it meant to be a subclass of DjangoObjectType for reuse later on, not and thus does not have a Meta class of its own.

Its also not possible to emulate DjangoObjectType by copying DjangoObjectType, subclassing the new class from ObjectType, this gets past assert is_valid_django_model(model) but then things run into trouble in graphene_django.registry.Registry which runs:

assert issubclass(cls, DjangoObjectType), 'Only DjangoObjectTypes can be registered, received "{}"'.format(cls.__name__)

Which fails due to the explicit check for DjangoObjectType.

It shouldn't require a fork of the entirety of graphene-django just to create a subclass of DjangoObjectType, either the Registry should be more flexible, or DjangoObjectType should be more flexible.

One option might be to use of Abstract Base Classes to enable a specific set of checks via https://docs.python.org/3/reference/datamodel.html?highlight=__subclass#class.__subclasscheck__

Another way would be to just drop these assertions and throw appropriate exceptions when we reach the situations they were designed to guard against. If we check that its a Django model to ensure that Meta exists, why not just throw a "Not A Django Model" exception when we try to do something later on that actually needs the Django model Meta information instead of asserting something way up the call stack that gets in the way of other things.

[roddds]

I just hit a similar issue. That check in DjangoObjectType essentially forbids subclasses, and I was depending on that to implement authorization. I'm open to suggestions on how to implement filtering per user in a straightforward way.

[techdragon]

@roddds At the moment, I've been forced to fork the entire graphene-django package to build on the features that I needed. I've built a solution for https://github.com/graphql-python/graphene/issues/572 which wasn't too hard once I worked out how everything was put together under the hood by django-parler and a little bit about how graphene-django inspects the model, but after working this out, I ran face first into this unable to extend/emulate issue.

Unfortunately, I haven't had the time to spend fully investigating how graphene and graphene-django work so that I can propose concrete changes to the code to resolve this. So for now I've stuck with the less than ideal, fork + branch with changes approach.

[taut-and-yare]

@techdragon Hi, could you please point out how you dealt with the specific django-parler issue (or share your fork). Thanks!

[danpalmer]

Ping on this, I've just hit this as a bit of a showstopper bug in our GraphQL implementation.

[borsden]

Is there any progress?

[miguel550]

Any progress?

[nwaxiomatic]

Also just ran into this issue trying to create an AutocompleteType that only allows two fields ("id" and "display"). Basically had to create a mixin I include with every Type that is supposed to be for the autocomplete query. Hopefully this gives another use case for this being useful.

[cobalamin]

A little ugly, but: personally I ~fixed~ worked around this by (in the subclass that's supposed to be a parent) referencing django.contrib.auth.models.User with a local registry that's never used again:

from django.contrib.auth.models import User

class MyDOTSubclass(DjangoObjectType):
    class Meta:
        model = User
        skip_registry = True

    additional_magic = ...

class SomeModelObjectType(MyDOTSubclass):
    class Meta:
        model = SomeModel

Why this works:

• User is always a valid Django model
• setting skip_registry = True makes it so that this ObjectType isn't registered for the User model, so you could still register a sensible ObjectType for that model if necessary anywhere in your application
• the Meta class isn't inherited to children, so skip_registry won't be True for them and they will be registered

Obviously this isn't nice in a number of ways, but if it's a showstopper for you otherwise :)

[danpalmer]

@cobalamin thanks for this! I've just applied this technique on our codebase it it worked perfectly. Our previous hack was to use a dynamic base class which mypy then couldn't inspect, so we've now got more idiomatic Python, simpler code, better linting and better typechecking!

[metakot]

But who stops you from using

class Meta:
    abstract = True

in a subclass ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[techdragon]

I think this should probably stay open since it represents a rather significant limitation that deserves some kind of solution.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[techdragon]

This should probably be reopened unless it's been fixed.

[nmanumr]

As mentioned by @techdragon this thing works for me:

class DjangoDynamicLoaderObjectType(DjangoObjectType):
    # ...
    class Meta:
        abstract = True

    #...