philipn/django-rest-framework-filters

Documentation on URL format inaccurate for DRF

tonimarie opened this issue · 2 comments

I was following your documentation and intending to use it with DRF. The URL format used in your documentation for the RelatedFilter was not working (returned all records instead of filtered records)

Just about when I was going to lose my mind, I was in my browseable API and DRF amazingly has a button to trigger the filters I'd now created... and by using that GUI I ended up getting the correct URL formatting.

Example:

Your format would say :
...api/inventory/hardware?asset__status__exact=Excessed

The correct format based on using DRF's API gui:
api/inventory/hardware?asset=&asset__status=Excessed

I don't know if it's my version of the browseable API (using Core API), but this worked for me with FilterSet called as a filter_class in a ModelViewSet.

EDIT: More accurate representation of the error and its result. I got two of my issues crossed the first time through. More testing required to describe that issue.

Out of curiosity, what versions of DRF, django-filter and djangorestframework-filters are you using?

Also, it should be necessary to use the asset param in order to use asset__status. Can you provide sample models and filtersets?

Hi @tonimarie, I'm going to close this as I'm unable to recreate the bug. I'm using the views from the test suite, and the following:

http://localhost:8000/users/?posts__title=foo

produces this SQL query:

SELECT "auth_user"."id",
       "auth_user"."password",
       "auth_user"."last_login",
       "auth_user"."is_superuser",
       "auth_user"."username",
       "auth_user"."first_name",
       "auth_user"."last_name",
       "auth_user"."email",
       "auth_user"."is_staff",
       "auth_user"."is_active",
       "auth_user"."date_joined"
FROM "auth_user"
INNER JOIN "testapp_post" ON ("auth_user"."id" = "testapp_post"."author_id")
WHERE "testapp_post"."id" IN
    (SELECT U0."id"
     FROM "testapp_post" U0
     WHERE U0."title" = foo)

My guess here is that asset__status__exact is not actually defined for your filterset. By default, filters that are generated for exact lookups do not include the __exact suffix in the filter name. It should probably be asset__status (which would make sense, as this is what was used in the second URL).