This is kind of an edge case, maybe? Maybe not. I ran into it because I have a field which is readonly on update but has a default for the create case.
See Serializer._writable_fields. I'm trying to do a partial update on one field, but I have another field that's readonly on update. BUT instead of being left alone, since it has a default, it always gets set TO THAT DEFAULT.
From my reading of writable_fields, it looks like this would happen with any field that has a default and isn't included in a partial update, but for it to happen on a read_only field seems particularly egregious to me. :-p
The text was updated successfully, but these errors were encountered:
I just updated to a DRF 3.4.5 and noticed this change in behavior between 3.4.1 and 3.4.2. This change is breaking a couple of tests for us and is also changing the semantics of how defaults are treated in DRF.
May I ask to not have such backwards incompatible changes in patch releases in future versions. Thank you.
Sure. That's always a bit more gray when the behavior is classified as a bug, but yes I do think that we'll start being more cautious about any change that affects behavior, even in bug cases, and deferring those to major releases.