Filtering not applied on related object list views?

[jonprindiville]

Here's a bit of odd behaviour that I've encountered. I feel like this is in error, but will have to do a bit more digging to be sure.

In the following examples, g is a gapipy client with the only options passed in being an application key (the g.com key, in this case).

---

Reproducing

First off, if we fetch a tour_dossier and then access the related departures listing, it can tell us what the count is (from the count attr on the JSON responses):

In [3]: g.tour_dossiers.get(24821).departures.count()
Out[3]: 1247

If we apply some filter, the count changes appropriately:

In [4]: g.tour_dossiers.get(24821).departures.filter(start_date__gte='2019-09-20').count()
Out[4]: 672

If -- instead of calling .count on it -- we iterate the result of the filter call, we seem to get the full unfiltered set of departures:

In [5]: len([d for d in g.tour_dossiers.get(24821).departures.filter(start_date__gte='2019-09-20')])
Out[5]: 1247

😢 What happened to my filters? I would expect to see 672 items here, same as where we used .count. This is the source of my confusion.

---

Contrast with...

... what happens when we query the departures list view directly, rather than reaching through a tour_dossier:

Filter for all the departures associated with that tour_dossier and we get the same 1247 value:

In [6]: g.departures.filter(**{'tour_dossier.id': '24821'}).count()
Out[6]: 1247

If we add on our date filter and use .count, again we get 672:

In [7]: g.departures.filter(**{'tour_dossier.id': '24821', 'start_date__gte': '2019-09-20'}).count()
Out[7]: 672

And here, the expected behaviour -- iterating that filter expression and we encounter the same number of items as when .counting it -- seems like the filtering persists in this case:

In [8]: len([d for d in g.departures.filter(**{'tour_dossier.id': '24821', 'start_date__gte': '2019-09-20'})])
Out[8]: 672

[marz619]

Fixed by #121 Not entirely fixed in #121

[jonprindiville]

👋 @marz619 I see you closed this -- thanks for following up, but I think that some problems remain.

I just wanted to follow up to confirm that the issue had been fixed, but I can't get through the reproduction instructions at all. Can you?

I've got gapipy==2.26.1 installed (and the latest version of the private repo as well) and then I try the following...

from gapipy_private import Client
g = Client(application_key='probably should not matter, but i am using a g.com key')
g.tour_dossiers.get(24821).departures.count()

... but I get an AttributeError: 'tuple' object has no attribute 'uri' at line 184 of gapipy.request:

gapipy/gapipy/request.py

Line 184 in 1110dec

self.parent.uri,

---

That g.tour_dossiers.get(24821).departures.count() call wasn't meant to indicate whether this issue was fixed or not, it was just meant to establish context for the other filtering calls done later on in the reproduction steps... so, hard for me to say whether the issue has been fixed or not.

[jonprindiville]

I see in your PR you created a namedtuple for that parent arg, but in my stacktrace I get a plain old tuple ... maybe related to this parent= stuff?

gapipy/gapipy/resources/tour/tour_dossier.py

Lines 56 to 57 in 5fe8ce0

	parent = ('tours', self.id, None)
	query = Query(self._client, resource_cls, parent=parent, raw_data=value)

[jonprindiville]

I should add: I see the same failure when I do from gapipy import Client as when I do from gapipy_private import Client -- not sure why I used private in my example.

[marz619]

@jonprindiville yup, adding the namedtuple broke the way the code functions. 🤦

We can remove that overriding behaviour in tour_dossier.py as we no longer use Tours as the base for querying against departures. My guess is this code was for a pre-Sieve era.