django-url-filter
django-url-filter copied to clipboard
miki725
Fixed bug in which DISTINCT clauses were forcibly removed from supplied querysets
I was supplying a queryset which was already distcint! And moreover I am using .distinct(field) in order to make a complex interaction between url filters and Window functions work. Works a dream in fact except that url_filter was clobbering the necessary DISTINCT ON clause in my query.
This is where it happened and it was because it paid no heed to the existing status of the query's distinct() setting. It need only apply distinct() if the caller has not already applied one (not least as called knows what fields they need to distinguish on.
I'm curious what the Travis CI failures are about? This is a two line change (much improved with your well informed insight (actually works now ;-), and I can't imagine that triggering any failures. Similarly I forked, cloned, ran make install and all dependencies are installed yet make test-all fails in a few places.
Can we see this two liner in a release some time (so I can rely on my production environment seeing it, right now it works on my dev box ...).
I should add while I'm here, that using .distinct() was clear error on my part. Not sure what I was thinking. The way I learn Django and other things as quickly as I can, is to complement my reading with object inspection. And so I paused my the code on that line, and examined the queryset looking down its properties. I swear I saw one called distinct with a value of True. So I went with .distinct. Memory is not a reliable beast ant it was late last night and was tired, but if it serves me, that crashed with some exception that suggested to me it was a method, so I just put () on the end and it all rolled. Of course queryset.distinct() if I wasn't half asleep at the time trying to close this issue off (finding this fixed a big problem for me of sorts) I would have noticed that that is a queryset and always returns true if there are any returned objects, doh! And has nothing to do with what I wanted, which was to test if the queryset already had a DISTINCT clause so to speak.
I should add I've worked around this, but I do wonder if this fixed fix will make into a release. Very quiet here no the front, given I have ni idea what All checks have failed by Travis means.
Fix looks good. Waiting for the ci to pass. Check Travis logs for exact error.
Hello @bernd-wechner, this would be a nice enhancement, could you please fix the travis-ci issue?
make: *** No rule to make target 'install-quite'. Stop. ERROR: InvocationError for command '/usr/bin/make install-quite' (exited with code 2)
Wow, my apologies, I sure dropped the ball on this one. Been months. I'm wonder how best to fix this, for lack of experience. It looks related to a simple tweak I made as an install-quiet command was misspelled install-quite in the Makefile. Shall I simply revert back to the misspelling? Or is there some way to inform Travis of the intent?
Hello @bernd-wechner, i think you should rebase onto master because that section of the Makefile was removed in latest version.
OK think I succeeded, somehow. git rebase is candidate for most confusing thing in the known universe of course. But the files changed on this PR now look clean. Waiting for checks to complete mind you. Hard to imagine this two line change will trigger any issues ;-)
Unfortunately, i think CI/CD server is not available at the moment. @miki725 can you please check it out?
Yes, it's been overnight and the check is still "Expected — Waiting for status to be reported", so it does appear to be down.