-
Notifications
You must be signed in to change notification settings - Fork 248
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
SerializerMethodField defaults seem to be treated incorrectly #422
Comments
interesting. apparently i would do this: class RecognizedFoodSerializer(serializers.ModelSerializer):
food_name = CharField(required=False)
serving_measures = serializers.SerializerMethodField()
class Meta:
model = RecognizedFood
fields = (
"urn",
"food_name",
"serving_measures",
)
def get_serving_measures(self, instance) -> typing.List[str]:
return (
instance.serving_measures if instance.serving_measures is not None else []
) i have reproduced your issue but i'm not quite sure whether this is actually missing functionality/bug or a "anti-pattern" we do not yet guard against. |
thanks for the quick response @tfranzel , I will try that out :) |
I spent some more time looking into this today. From my reading of the DRF code, it looks like both their docs and our code are incorrect (which feels kind of unlikely). Here's what I see During a call to
For a
and the
To me, this seems to show that what is passed in to While investigating this, I happened to see that
I wonder if |
I got a test case going (https://github.com/rmelick-vida/drf-troubleshooting), and confirmed that the DRF docs are correct: the value passed into While stepping through the debugger, I saw what was happening. When the If you run the example, and start up the server using
But, when generating a schema, it is passed the list
What do you think, should we open a ticket / issue within the DRF project to ask them why they're inconsistent in the parameters that |
@rmelick-vida thanks for taking such a detailed look at this. i gave it a quick glance to provide you with a first opinion. however, i have to have a bit more time to look at it in detail and give you a more definite answer. what i can tell you already is that the likelihood of them changing such a seasoned API is small unless this is a serious bug, which i'm not yet sure about. also we do call just a first opinion which may turn out wrong, but i will schedule some time in the next couple of days for this. |
Hi @tfranzel I wonder if you had a chance to think any further about this. |
@rmelick-vida sry it fell of the wagon and i was busy. I had a look again and came to the conclusion that simply using the plain value is pretty much the only thing we can do with does this fix work for you? |
Hi @tfranzel I think this is the right solution, but we also need to add the special case for |
good point! i missed that one. that should do it |
closing this issue for now. feel free to comment if anything is missing or not working and we will follow-up. |
Hi @tfranzel confirmed, the fixes work great! Thanks for the help :) . |
Describe the bug
I was trying migrating my project to use
drf-spectactular
, and ran into an interesting exception when trying to generate the schema for the first time.I ran
and got an exception with the following stacktrace
To Reproduce
Here's a stripped down version of the Serializer and Model class I was using (I removed a bunch of other fields since it's from our production codebase)
Expected behavior
It appears that when trying to generate the schema for this
serving_measures
field, thedrf-spectacular
code is passing in the default value of the field (an empty list) as the second parameter to theget_serving_measures
method. The drf codebase hasIf I read the DRF docs for SerializerMethodField, I believe these functions need to be written to expect the entire object to be passed in as the second argument (a
RecognizedFood
in my example), not just the value of that field (the empty list).Am I misunderstanding something?
The text was updated successfully, but these errors were encountered: