-
-
Notifications
You must be signed in to change notification settings - Fork 546
pass-through for Schema-based results #1497
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
base: master
Are you sure you want to change the base?
Conversation
When the response-parameter is filled and the result is already a Schema we don't need to verify it again.
|
+1 This would be helpful |
|
I guess this also need a validation taht returned object is one of the responses (e.g BlogPageSchema | HomePageSchema ) |
|
hi @vitalik thank you for looking into this. to be honest, i dont understand 🫣 isn't that exactly what the |
hm migth be - le'ts also add a test to cover :
|
|
I changed it to Can you give me a pointer where best to add a test for this? Cheers |
|
forgot to mention: i added a test 👍 ready to be merged i think |
When the response-parameter is filled and the result is already a Schema we don't need to verify it again.
Brief reasoning for the situation:
Wagtail has a [new guide how to integrate Ninja](based on https://docs.wagtail.org/en/v7.0/advanced_topics/api/django-ninja.html).
In it they use this
This works but has its issues since basically the returned Page type (the django Model) is tried to be fitted against all different
response-Schemata. Obviously that's a performance issue but it brings other problems too, which I dont want to go too deep into.So my solution would be:
this does currently not work, because the result is being re-parsed, because I have
responseset in the decorator. Obviously I could remove that but then I'd lose the types.This PR allows Schemas to be directly returned, assuming that the validation already has happened.
Thanks so much