@encode/django-rest-framework-core-team Can I ask for input on this please? Breaking BC for a long-standing behaviour isn't top of my list of things to do.

Thanks.

Fixes#5708, by addingdefault=None to the Field definition.
@carltongibson For what it worth, BC has been broken since 3.7.4 for us already. So I would be relieved if we break it again so we can use DRF upstream.

Hi@ticosax.#5708 is on my radar here. There's a little bit of unpicking to do to get to it directly though. (There are a few related points.)

Following this I'm expecting now that we will revert#5639.

I'm then hoping that we've pinned down the whole nest of issues here.

To wit: any test cases you think are missing, anywhere in this ballpark would bevery welcome.

I think I made a mistake in my previous comment. there is no relation between the fixed behavior in our test suite and this PR. sorry. I will try to isolate better the changes.

Yup looks good to me, and I think it's more intuitive behaviour this way around.
Good sign that there's only that one test case that needs tweaking.

With this change, what is the correct way to do unique-together validation where one of the fields is a read-only field?

In my case,(owner, name) are unique-together, and owner was previously set implicitly via

owner=serializers.PrimaryKeyRelatedField(read_only=True,default=serializers.CreateOnlyDefault(serializers.CurrentUserDefault()),    )

but that field is now ignored.

Whenowner is passed in viaserializer.save(...), validation has already run and there are no(owner=None, name='...') duplicates even if there might be one when the owner is actually set, and so the view crashes with a database integrity error (500 Infernal Server Terror).

Hi@akx.

Can you put that into a minimal test-case please?

Theunique_together validation ismeant to be preserved, but it may not be covered.

Relevant test case is in

It has a case for read-only fields:

So we may need to make an adjustment.

@carltongibson Sure thing. Here you are:https://github.com/akx/drf_unique_together_testcase

I get error 400, as expected, on DRF 3.7.x, and an IntegrityError on DRF 3.8.x.

@akx Awesome thanks. I'll have a look.

@carltongibson Should I create an issue for this, erm, issue, for better tracking?

@akx I'm hoping#5922 resolves this. Please give it a run. 🙂

Would it be worth adding a note tohttp://www.django-rest-framework.org/api-guide/validators/#advanced-field-defaults where it says

Using a standard field with read_only=True, but that also includes a default=… argument. This field will be used in the serializer output representation, but cannot be set directly by the user.

Thedefault argument is still necessary for having the value present at validation time, but additionally the value needs to be passed viaserializer.save().

Yeah, maybe. It is mentioned in the unique_together docs, but calling it out further may have value.

I wonder if overridingcreate on the Serializer is a good way to work around / fix this:https://github.com/lock8/django-rest-framework-jwt-refresh-token/pull/35/files#diff-84229b1d4af72d928beddfa32e80cc8eR23

@blueyed: Yes — that's one way. Either, in the view with theperform_create hook, passing theuser tosave(), or in the serialiser overridingsave() orcreate() orupdate() as appropriate.

The key is that (because of the whole history here) we need the user to pass the value on save somewhere.

The question is how best to add that to the docs. (I don't think it'll need much.) You're the ones reading them: PRs welcome 🙂.

It was cool that I got to spend a day-and-a-half trying to figure out why I was getting apsycopg2.IntegrityError just because I upgraded fromDRF 3.7. Would maybe have been nice to have had an exception raised that said something like "Hi. We noticed that you've got a read-only field with a default value. We thought you might like to know that we changed how we handle such things. Here's a helpful link to our issues page on github. Have a nice day!"

:-\

This was nearlythe headline of the 3.8 release notes.

Hi@mikelane. Contributions and suggestions are always welcome. If you have a minimal example where the behavior is suboptimal and what a helpful exception might have been, it would be appreciated. There's always a chance to improve the error handling and assertion guards.

The docs are misleading on this issue:
https://www.django-rest-framework.org/api-guide/validators/#using-with-a-read-only-date-field

Hi@johnmatthewtennant. Can you be more specific on what's misleading? Also, if you have the time, opening a PR with a documentation update would be helpful. If not, just open a separate issue so we don't lose track of the discrepancy.

The docs recommend

"If you want the date field to be visible, but not editable by the user, then set read_only=True and additionally set a default=... argument."

It then says:

"The field will not be writable to the user, but the default valuewill still be passed through to the validated_data."

This is not true. It willnot be passed through to the validated_data.

Thanks - I opened a new issue pointing to your comment so this isn't forgotten.