Redundant resolver with unused arguments when filtering with prefetch

[rcybulski1122012]

There are cases, where I need to implement a resolver that returns related objects filtered based on user input. Currently all the filtering logic is implemented "inside" prefetch_related and the resolver only returns the prefetched fields, but it has to define arguments, which are unused by resolver.

Example:

    @strawberry_django.field(
        prefetch_related=lambda info: Prefetch(
            "some_related_objects",
            queryset=optimize(
                SomeRelatedObject.objects.filter(
                    **(
                        {"is_confirmed": is_confirmed}
                        if isinstance(is_confirmed := get_field_args(info).get("isConfirmed"), bool)
                        else {}
                    ),
                    period__contains=get_field_args(info).get("date", timezone.now().date()),
                ),
                info,
            ),
            to_attr="prefetched_some_related_objects",
        )
    )
    @staticmethod
    def some_related_objects(
        root: User, date: date | None = UNSET, is_confirmed: bool | None = UNSET
    ) -> list[SomeRelatedObjectType]:
        return root.prefetched_some_related_objects

The get_field_args function I use here, returns a dictionary of field arguments - related issue.

I'm not sure how this problem should be solved (maybe a different kind of decorator that is specific for such cases, instead of taking lambda as an argument of prefetch_related). I'm not even sure that's the proper way of solving this type of problems 😅 - as I mentioned in a different issue, more specific optimizer documentation would be appreciated 🙏

Feature Request Type

• Core functionality
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

[rcybulski1122012]

It just occurred to me that the example in the description will fail if someone used aliases..

[rcybulski1122012]

Another thing occured to me. What if want want to use filters and ordering. In theory I can call apply_filters and apply_ordering, but it's becoming a mess :/

Also in some cases it's impossible because apply_filters requires the filter to be a django object, but in my implementation of get_field_args returns a dictionary. I cannot create filter objects because it's not even imported (due to circular imports).

The only option that is left there is to write a dataloader :/

[rcybulski1122012]

New possible syntax came to my mind. This could be similar to how properties work

@strawberry_django.field
@staticmethod
def some_field(parent: strawberry.Parent[Model]) -> int:
    pass

@some_field.prefetch_related()
@staticmethod
def prefetch_some_related_field(info: Info, date: date | None = UNSET) -> Prefetch:
    qs = Related.objects.all()

    if date:
        qs = qs.filter(period__contains=date)

    qs = optimize(qs, info)

    return Prefetch("related", queryset=qs, to_attr="prefetched_related")

It's just an idea. Redundant arguments are not a big problem. This causes that the arguments are defined outside the resolver and that the biggest drawback

[bellini666]

Asked claude to create #881 as a PoC

What do you think?

[rcybulski1122012]

@bellini666

This may be useful! I left a comment with my implementation of field arguments retrieval (btw, shouldn't this be part of strawberry instead of strawberry-django?)

Although I don't like few things:

• To provide a function to prefetch/annotate I can declare a lambda which is not very readable if prefetch is complex, or define a function which will be above the type definition (or in another file), which forces me to scroll of look for the implementation in another file 🤔. The second case isn't that bad - the same is with dataloaders.
• I still have to define arguments which are not used in the field resolver, and my code editor complains about it (this is what the issue was about in the first place 😅)

Maybe there is no solution to this problem if we rely on function signatures 🤷 This is not a serious problem, I just wanted to share what I came across 😄