NestedViewSetMixin returns ValueError if the wrong pk type is given in URL

[frwickst]

Lets say you have the following nested url:
/books/23/pages, which works fine, and then change the url to
/books/NOT_AN_INTEGER/pages
this will cause the server to throw:

ValueError at /books/NOT_AN_INTEGER/pages
invalid literal for int() with base 10: 'NOT_AN_INTEGER'

...
/rest_framework_extensions/mixins.py in get_queryset
        60.  super(NestedViewSetMixin, self).get_queryset() 

/rest_framework_extensions/mixins.py in filter_queryset_by_parents_lookups
        67.  return queryset.filter(**parents_query_dict) 
...

The route is of course wrong, but it should return 404 and not a 500 error

I am running:
Django 1.7
djangorestframework 3.1.1
drf-extensions 1.5.2

[frwickst]

A suggestion for a fix here is to have a try-except around queryset.filter() like so:

from rest_framework.exceptions import NotFound
...
    def filter_queryset_by_parents_lookups(self, queryset):
        parents_query_dict = self.get_parents_query_dict()
        if parents_query_dict:
            try:
                return queryset.filter(**parents_query_dict)
            except ValueError:
                raise NotFound
        else:
            return queryset

This would cause the server to respond with 404 Not Found instead.
I don't know if this is something you want to do or of you have a better solution in mind. I'll create a pull request if you think this is enough :)

I noticed that Django did something similar here:
django/django@e2ee02c

[maryokhin]

This is because the url kwarg lookup allows non-integer regex. A proper solution would be to allow the user to set the lookup_value_regex on the viewset (failed attempt #63). This is issue just shows that without a solution this can actually be considered a bug.

[frwickst]

Sorry, but I don't see that as a proper solution. That would put the responsibility on the developer using drf-extensions, to see to it that a 500 error is thrown on a default setup. That is not OK in my book at least.

The problem here is not that the router does not handle custom regex values, but that it tries filtering a query with non-proper values.

I have created a pull request with the fix I thought was temporary but seems to be the proper one after creating #87.

[auvipy]

PR?

[auvipy]

@frwickst this issue should be open to be fixed with workaround?