As per@tomchristie'scomment this might not be the right fix.

Related:https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/serializers.py#L461-L472

and

Question is why that's not catching the None case. Are we always failing to do so for related fields, or is there something different in this case?

Right. Progress.

Slapping a breakpoint in where@tomchristie said reveals the problem:

rest_framework/serializers.py(469)to_representation()-> if attribute is None:(Pdb) fieldPrimaryKeyRelatedField(allow_null=True, pk_field=UUIDField(), queryset=[])(Pdb) attribute<rest_framework.relations.PKOnlyObject object at 0x1122de7d0>(Pdb) l464                 except SkipField:465                     continue466     467                 import pdb; pdb.set_trace()468     469  ->             if attribute is None:470                     # We skip `to_representation` for `None` values so that471                     # fields do not have to explicitly deal with that case.472                     ret[field.field_name] = None473                 else:474                     ret[field.field_name] = field.to_representation(attribute)(Pdb)

In this case at leastattribute isnotNone, even though the relation inNone. Instead we have aPKOnlyObject object.

Where a foreign key is nullRelatedField.get_attribute will returnNone isall cases except whereuse_pk_only_optimization returnsTrue. Only then will the existingattribute is None check give the wrong result.

Thus in2ef74cf I resolve thepk value before checking forNone. This allows thead hoc code added toUUIDField to be removed, and the added tests still pass. 🎉

I'm happy to adjust the formatting of theA if B else C if you don't like that.

Otherwise I think this is probably the right fix. Thoughts?

Just milestoning this to keep it on the radar.

@carltongibson does this need a review ?

I think it's the right fix — but I'd be happy if you or@tomchristie could just think it through... — is there another case we've missed? (Or shall we handle that if/when it comes up)

It looks good to me. I don't see other cases.
Let's move on.

On a side note, I'd be interested in discussing the design (ping@tomchristie) esp. why this has to be in the serializer as opposed as@carltongibson's initial proposal - which was to handle that within the field.

Nice job 👍