DjangoObjectType duplicate models breaks Relay node resolution

[boolangery]

I have exactly the same issue as #107.

The proposed solution no longer works

How to do this now in the current state ?

[boolangery]

Here is my temporary solution for this bug:

class FixRelayNodeResolutionMixin:
    @classmethod
    def get_node(cls, info, pk):
        instance = super(FixRelayNodeResolutionMixin, cls).get_node( info, pk)
        setattr(instance, "graphql_type", cls.__name__)
        return instance

    @classmethod
    def is_type_of(cls, root, info):
        if hasattr(root, "graphql_type"):
            return getattr(root, "graphql_type") == cls.__name__
        return super(FixRelayNodeResolutionMixin, cls).is_type_of(root, info)


class PublicUserType(FixRelayNodeResolutionMixin, DjangoObjectType):
    class Meta:
        model = User
        interfaces = (graphene.relay.Node,)
        fields = ['id', 'first_name', 'last_name']

class UserType(FixRelayNodeResolutionMixin, DjangoObjectType):
    class Meta:
        model = User
        interfaces = (graphene.relay.Node,)
        fields = ['id', 'first_name', 'last_name', 'profile']

[matt-dalton]

Also struggling with this.

The solution above looks pretty decent, thanks @boolangery , although I'm slightly nervous it will lead to edge cases down-the-line. Seems weird that there's not some official support - building public versions of nodes is surely a basic use-case.

[matt-dalton]

Although I've just tested it and it seems to not work for me...very similar setup to you.

Does this query output the same IDs for users and publicUsers @boolangery ?

{
   viewer {
       users {
          id
       }
       publicUsers {
          id
       }
   }
}

That's what I'm trying to achieve

[absolutelysimon]

Has there been a fix for this? I am running into the same issue.

[overide]

Same here, is there any proper fix for this?

[tony]

I recreated this at #1291 clarified with a complete description, thorough example and history of the issue.

Can we please close this in favor of #1291 to make the problem easier to track down so we can get a PR?

[tony]

@keithhackbarth @zbyte64 @graphql-python I remade the issue from scratch to document the bug at #1291, can we close this in favor of that? It took me a few hours of searching (inside and outside GitHub) to find this issue existed all along

[tony]

@boolangery would you also be open to using my issue content in your post (I can close mine) or potentially closing this in favor of #1291? (As long as it's easier for people to see this is a documented issue, I'm fine with whatever the solution is)