Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix tests for django-filter 1.0.0 #122

Merged
merged 3 commits into from Nov 22, 2016
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 2 additions & 6 deletions README.rst
Expand Up @@ -429,10 +429,6 @@ Example result response (cut to one element only instead of 10):
Filters
-------

**note**: this feature is compatible with django-filter up to version 0.15.
If you need compatibility with version django-filter 1.0 please send a patch
(see `issue #120 <https://github.com/djangonauts/django-rest-framework-gis/issues/120>`_).

We provide a ``GeometryFilter`` field as well as a ``GeoFilterSet``
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave something like: "this feature has been tested up to django-filter 1.0".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not mention that explicitly: it needs updating later etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The library (documentation, tests, changelog) needs to be updated anyway at each release. If django-filter becomes stable and won't introduce backward incompatible changes I wouldn't mind deleting the note, but this dependency has caused quite a few issues recently and I prefer to do it this way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh.. the reason for 1.0.0 is exactly to become stable - all the deprecations have been dropped.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right, in theory. Let's see if it also translates into practice.

for usage with ``django_filter``. You simply provide, in the query
string, one of the textual types supported by ``GEOSGeometry``. By
Expand All @@ -446,8 +442,8 @@ GeometryFilter
from rest_framework_gis.filterset import GeoFilterSet

class RegionFilter(GeoFilterSet):
slug = filters.CharFilter(name='slug', lookup_type='istartswith')
contains_geom = filters.GeometryFilter(name='geom', lookup_type='contains')
slug = filters.CharFilter(name='slug', lookup_expr='istartswith')
contains_geom = filters.GeometryFilter(name='geom', lookup_expr='contains')

class Meta:
model = Region
Expand Down
2 changes: 1 addition & 1 deletion requirements-test.txt
Expand Up @@ -2,5 +2,5 @@ psycopg2
djangorestframework>=3.3
coverage==3.7.1 # rq.filter: >=3,<4
coveralls
django-filter>=0.15,<1.0
django-filter
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with experience I've learnt that restricting the versions in use is good, especially when the dependencies introduce backward incompatible changes.
This line doesn't affect the library during installation but only in travis builds, this will avoid our builds to break if a new (unsupported yet) version of django-filter intrdocues backward incompatible changes.

Therefore I would put django-filter>=0.15,<1.1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's good to be notified in case of issues with new upstream versions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

immagine the case in which we receive a bug free pull request and the build fails because of a new incompatible version of django-filter: that's annoying, because the pull request works and can be merged but the CI build would fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I know.. but it helps with being notified.
I can see your point though, so feel free to pin it.
(As for myself as a PR submitter, in case I notice that it fails because of something minor, I often just create another PR to fix it, too)

As for pytest-django we also test against Django master, but that job is allowed to fail: when there are several jobs you can see what the cause of the failure is more easily.
So an option might also be to test against pinned and unpinned versions of django-filter (possibly via #123).

contexttimer
4 changes: 3 additions & 1 deletion tests/django_restframework_gis_tests/views.py
Expand Up @@ -132,10 +132,12 @@ class GeojsonLocationNoIdDetails(generics.RetrieveUpdateDestroyAPIView):


class LocationFilter(GeoFilterSet):
contains_properly = GeometryFilter(name='geometry', lookup_type='contains_properly')
contains_properly = GeometryFilter(name='geometry',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure removing lookup_type='contains_properly doesn't break compatibility with older django-filter versions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is only for the test.
So as long as you do not want test against older django-filter versions this should be fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right

lookup_expr='contains_properly')

class Meta:
model = Location
fields = ['contains_properly']

class GeojsonLocationContainedInGeometry(generics.ListAPIView):
queryset = Location.objects.all()
Expand Down