Default lookup expressions

[isaac-blanc]

This is a very minor complaint, but I am curious to know if there is an easy fix.

Example

I have been using a FilterSet with the fields defined in a list.

class UserFilter(django_filters.FilterSet):
    class Meta:
        model = User
        fields = ['username', 'last_login']

I have been sending requests to this endpoint as shown below. The FilterSet seemingly interprets these as exact lookup by default.

response = requests.get(url, params={'username': 'ella'})

I then realise that I want to add support for in lookup, so I change to defining the fields in a dictionary.

class UserFilter(django_filters.FilterSet):
    class Meta:
        model = User
        fields = {
            'username': ['exact', 'in'],
            'last_login': ['exact', 'in'],
        }

Now I must append __exact or __in to my query params.

response = requests.get(url, params={'username': 'ella'}) # no longer works
response = requests.get(url, params={'username__exact': 'ella'})
response = requests.get(url, params={'username__in': 'ella, greg'})

Problem

It seems unfortunate that adding support for in lookup changes the API for exact. I would have thought it would make sense for the first lookup option to be handled as a default. That way, existing calls to the API don't need to be changed when I add support for in lookup. Is there an easy way to do this?

[carltongibson]

Hey @isaac-blanc — Erm... what you describe as desired is the actual behaviour — or it should be.

From the test suite:

    def test_meta_fields_dictionary_derived(self):
        class F(FilterSet):
            class Meta:
                model = Book
                fields = {
                    "price": ["exact", "gte", "lte"],
                }

        self.assertEqual(len(F.declared_filters), 0)
        self.assertEqual(len(F.base_filters), 3)

        expected_list = [
            "price",
            "price__gte",
            "price__lte",
        ]
        self.assertCountEqual(list(F.base_filters), expected_list)

The form there has the price field you're looking for.

So something else must be going on in your case.

[isaac-blanc]

Thanks for the reply! On further investigation, I realised the error was coming from my workaround in #1719. Apologies for not noticing this before.

I briefly looked at improving my workaround, but to no avail. I'm sure it would be possible, but I don't think its important enough.