Non-obvious moments when overloading the Connection

[iamcrookedman]

Hello
I tried to define a custom Connection class to extend it with the data I need.
For this, the Node class was also redefined, and I encountered non-obvious behavior when defining the resolve_connection method

def _has_own_node_resolver(cls, name: str) -> bool:
    resolver = getattr(cls, name, None)
    if resolver is None:
        return False

    if id(resolver.__func__) == id(getattr(Node, name).__func__):
        return False

    return True

It turns out that the method described in the Node class is replaced by default with another one, and when defining a custom class, it is impossible to call super of the parent class
In other words, when defining a class and at runtime, we have different resolvers
What is the reason for this behaviour? Wouldn't it be better to immediately set the necessary behavior in the Node class?

[bellini666]

What is the reason for this behaviour? Wouldn't it be better to immediately set the necessary behavior in the Node class?

The relay implementation was written to be as generic as possible, to be able to use with non-django types as well. The django type replaces the NotImplemented methods with their own, which resolves them taking querysets into consideration.

I understand that it makes using super impossible, but it is basically a limitation of the dataclass approach that strawberry in general uses. For example. when using @dataclasses.dataclass and passing eq=True or order=True, since the class already exists when it is being processed, those methods will be injected in it if they don't exist, meaning they are part of the MRO and super also cannot be used.

Currently the only way to call the original method is actually to call the method they are calling by hand. For example, if you define your own resolve_connection, you can just call resolvers.resolve_connection and pass the relevant args to it, just like the injected methods does.

But I'm open to suggestions on how to improve this