@carltongibson @blueyed Is this obsolete since 3.8?

Does it still pass if rebased on master?

I haven’t yet examined this one explicitly.

Looking then, this was resolved by #5849 I think. @blueyed please comment if not correct and we can review.

@carltongibson

Deserialization of the nullable foreign key field throwing the issue of 'NoneType' object has no attribute 'foreign_field'. Have tried setting default as None.

Django RestFramwork Version: 3.8.0

Hi @arpit-draup. If you could provide a failing test case (e.g., as a PR), that would be helpful.

@rpkilby I have found the workaround -
demo = CharField(source='demo.name', allow_null=True)
but I have one question if we have already set null=True and default None in the model then why this None check has been removed after DRF 3.6.4 - link

Could you provide more details? I'm not following what you're asking.

@rpkilby Can you please check this link : Stackoverflow. I have mentioned in detail.

if we have already set null=True and default None in the model

Except that since you override the generated field with an explicit field, whatever you did set on the model doesn't count.

@xordoquy okay For serializer we have to set explicitly Is it? but before it wasn't like the same
Why this None check is removed : Link

Edit :
Serializer works on the model field right if the model has a particular property it should follow while deserializing or serializing the data Isn't it ?

There has been some changes the way default values are handled for serialization. As far as I can tell it's been in the release notes.

@xordoquy Okay but you understood the point, I am trying to make here?
Before if we have allowed the null in the model, serialization and deserialization worked perfectly without explicitly allowing null into the serializer.

Why this None check is removed...

There were a whole bunch of issues around #5849 here. Unfortunately the old behaviour led to incorrect results, particularly with dotted-sources and default handling. We were forced to adjust, for v3.8.

It gets pretty complex here. Without a failing test case in a separate PR it's not something we can think about changing easily.