-
Notifications
You must be signed in to change notification settings - Fork 301
Using EXCEPTION_HANDLER is not compatible with multiple DRF configurations #214
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
Comments
For now I imagine that the best workaround would be to create a mixin that overrides the DRF If we moved the exception formatting to the renderer what would be the nicest API to call it with? Are you setting the DRF renderer or the DRF-JA renderer on each view class? I'm happy to review a pull request if you have time to implement something. I would think this code could easily be extracted to a |
I have one base class with all DRF-JA settings that every API View inherits. Will take a look at it. |
Looking at the DRF interface the best way would be to change it a bit - encode/django-rest-framework#4045 - if that gets merged no change to exception handle would be needed, as it could be set via method override. |
Closed by #222 |
* docs: note about importing serializers * Document ResourceRelatedField and RelationshipView * Updated pip install instructions for 2.0.0-beta.2 * Add LimitOffsetPagination * Dont let the offset go into negative space * Add basic unit test for LimitOffsetPagination * Support deeply nested includes Allow skipping of intermediate included models * Add current tox.ini directory to PYTHONPATH in order to use imports form there Fix regression on PY3 caused by unicode_literals * [FEATURE]: support using get_serializer_class on view * fixed extract_root_meta for lists * Fixed get_resource_name in case of non-model backed serializer. Closes #219 * ResourceRelatedField now accepts serializer methods when many=True * Rename "suggested" posts to "featured" so we can use suggested as many=True * Updated SerializerMethodResourceRelatedField to allow many=True Issue #151 Closes #220 * Correct error responses for projects with different DRF-configurations (#222) * [#214] Add error messages tests. * [#214] Extract formatting DRF errors. * Add example view with custom handle_exception. * Use HTTP 422 for validation error responses. * Add full example of class-configured json api view. * Fixed naming that suggested settings were used to inflect relationship names. JSON_API_FORMAT_RELATION_NAME actually inflected the `type` instead. The relation name is not changable at this time although if it woudl be useful to someone it would be fine to implement it. Closes #136. * Updated changelog * Added a doc note to prefer setting resource_name on serializers or models. Closes #207 * Added get_related_field_name method to RelationshipView * Added get_related_field_name method to RelationshipView * Added docs about field_name_mapping * Updated the readme for testing (#234) * Allow exception handler to be used by normal DRF views: (#233) * Add top-level 'errors' object to non-JSON-API responses * Allow configuring the exception handler to be used _only_ in JSON API views or uniformly across all views * Fix included resource type inconsistency (#229) When setting `resource_name = None`, the related instance's resource name is used in `relationships`, but `None` is used in `included`. This is related to #94 and #124 * Fixes #230. Keep write only fields from having an attribute key * Release v2.0.0 * Update setup.py to classify as production/stable
To get proper error responses EXCEPTION_HANDLER must be set as mentioned in #188 however EXCEPTION_HANDLER is the only setting that can't be set on a class, thus preventing multi-configuration projects - I have vanilla-DRF and JSONApi views in the project.
The source of the problem is in https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/views.py#L413 where exception_handler = self.settings.EXCEPTION_HANDLER
I asked on DRF irc channel about it and it was suggested that the renderer itself could handle that error response formatting. Can't say how that would fit, but it's either that or slight modification to the base view class in DRF so that it's easier to change the exception handler (instead of hacking with deepcopy of self.settings or copy-pasting the whole method).
The text was updated successfully, but these errors were encountered: