REGRESSION: default resolvers

[rafales]

This commit: 9a0f740

started setting resolver on fields. Providing a resolver for all fields breaks usage of default_resolver (meta param to ObjectType), which our project was using. This introduced a silent error, where our default resolver was not called.

[jnak]

Hello, Thanks for reporting the issue. Can you share more about how you relied on the default_resolver? I believe graphene-sqlalchemy had a big dependency on attr_resolver so it's not clear to me how it could work with a different default_resolver.

[rafales]

Up until the latest version (2.2.1) graphene-sqlalchemy did not use any custom resolvers.

We have something built on top of graphene that uses default_resolver for some access-related logic. Basically what happens is something like this:

attrs_dict = {
    "Meta": {
        "model": self.db_model,
        "default_resolver": self.default_field_resolver,
        "only_fields": only_fields or (),
        "exclude_fields": exclude_fields or (),
    }
}

graphene_type = type(
    self.db_model.__name__, (SQLAlchemyObjectType,), attrs_dict
)

[rafales]

Everything is fine and our default_field_resolver gets called in versions <2.2.1, but in 2.2.1 default_resolver never gets called for SQLAlchemyObjectType descendants.

[jnak]

Would you mind explaining what type of logic you are putting in default_field_resolver? We need understand the use case if we are going to consider supporting explicitly it via test and documentation.

[dtamez]

In our case we had a few places where we had a resolver on a type but did not explicitly have the field on the type. The type was defined as a SQLAlchemyObjectType and the field(s) in question were not in the excluded fields list. Our resolvers were defined on the type and required extra logic before returning and could not simply be returned from the database. One example was images that were being stored in AWS S3 with presigned urls that had an expiration date.
Before 2.2.1 the resolvers for those fields were being called and executed. With 2.2.1 the resolvers no longer got called. For now we have pinned the lib to 2.2.0 until this gets fixed or a decision is made that it should not be fixed.

[davidmoss]

I experienced this regression too, where my resolver_<field> stopped getting called in v2.2.1 for objects in a queryset.

[jnak]

Can anyone share an actual repro of the bug? thank you

[ticosax]

@jnak please check #235 to repro the bug, if I understand correctly

[davidmoss]

@ticosax looks good to me

[jnak]

Apologies for the late reply. I was on vacation and did not have time to look into this until this week.

Thanks @ticosax for the repro. I figured out what's going on. It's indeed a serious regression :/
I have a fix that is mostly done, I just need to address a TODO. I'll finish it early next week.
Here is the branch in case you need the fix now.

Cheers

[jnak]

@davidmoss @ticosax @dtamez Here is the fix: #241

@rafales Does my PR fix your issue? It seems that the repro posted by @ticosax is different from your original issue with default_resolver. I don't understand how you are using default_resolver without interfering with SQLAlchemyObjectType resolve its fields. Can you share some more details?