-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Validation error codes with string like object #3775
Validation error codes with string like object #3775
Conversation
Adding this to the 3.3.3 milestone to keep on our radars. |
Looking feasible at this point. One way to move forward - take a stab at documenting (even if only in the comments) - how does a developer get access to the status codes in an error. Are they visible only if working with the serializer explicitly, or are they available to the existing error handler without any further changes? |
Error codes are available everywhere the error strings are available, so basically at every level. I Will add decent documentation asap (dont have access to my computer until tomorrow). |
So to be more specific:
No.
Yes. See here: https://github.com/tomchristie/django-rest-framework/pull/3775/files#diff-3a4f34405474c71b1b3c0a0a3b2fbf28R32 |
@tomchristie : do you want me to go more in depth and come up with an actual markdown doc update or is it enough for now? (I'm open to do it, just asking) |
@johnraz - It's okay in it's current state - thank you! Still on the backlog, and still queued up behind other stuff that I'm having to focus on ATM - apologies as ever for the snails pace. |
7971343
to
c62d19f
Compare
@tomchristie, @xordoquy rebased, hoping to bump this up a little ;-) |
This is great! Do we need any change on this? If you need any help, please let me know! :D |
it is awaiting final review and |
ping @tomchristie: I put quite a few efforts on this and would really like to see it going forward as I need the feature badly and I'm sure i'm not the only one 😄 Just trying to promote the feature a little bit more here 😉 |
c62d19f
to
2668611
Compare
I'm still lukewarm, but not going to write it off.
It might be useful to see an example of how you'd use this together with some view code or custom exception handler. |
There is already an example in the tests here, I can put together a more detailed example if that would help you get your head around it, just let me know. |
This patch is meant to fix encode#3111, regarding comments made to encode#3137 and encode#3169. The `ValidationError` will now contain a `code` attribute. Before this patch, `ValidationError.detail` only contained a `dict` with values equal to a `list` of string error messages or directly a `list` containing string error messages. Now, the string error messages are replaced with `ValidationError`. This means that, depending on the case, you will not only get a string back but a all object containing both the error message and the error code, respectively `ValidationError.detail` and `ValidationError.code`. It is important to note that the `code` attribute is not relevant when the `ValidationError` represents a combination of errors and hence is `None` in such cases. The main benefit of this change is that the error message and error code are now accessible the custom exception handler and can be used to format the error response. An custom exception handler example is available in the `TestValidationErrorWithCode` test. We keep `Serializer.errors`'s return type unchanged in order to maintain backward compatibility. The error codes will only be propagated to the `exception_handler` or accessible through the `Serializer._errors` private attribute.
`ValidationErrorMessage` is a string-like object that holds a code attribute. The code attribute has been removed from ValidationError to be able to maintain better backward compatibility. `ValidationErrorMessage` is abstracted in `ValidationError`'s constructor
2668611
to
2bf6ee4
Compare
@tomchristie: getting back to this one again, rebased on master and also simplified the commit history a bit. |
Gotcha, will make sure to consider it for 3.5 yup! |
@johnraz Thanks for your great work. I am trying to understand your changes a bit more as I would like to see this arrive soon / help in some way. This PR brings:
Is that correct? The
Finally, is there documentation on the way for this? I could help if needed. |
@lwm you got the grasp of it yes. The fact that the ValidationErrorMessage looks like a string is made on purpose to avoid breaking ValidationError (point 2). There is no documentation yet. |
Mmm one thing I overlooked in what you wrote, the new code API is on ValidationErrorMessage.code, not on ValidationError itself. |
@tomchristie I've just been told the customer I'm working on this for, just started sponsorship on the project 🎉 Hope this will help you push this forward! |
👍 |
Now superseded by #4550. |
This one is here to help compare work done in #3716