clean_fields(exclude=["pk"]) not implemented for composite primary keys

[Jacob Walls]

Passing exclude=["pk"] to full_clean() / clean_fields() has no effect: the underlying fields have to be provided instead.

This "no effect" might be silent (coercing a value when you didn't expect) or loud (raising ValidationError) given that we don't raise ValueError for providing an extraneous field name.

I'm suggesting we either implement exclude=["pk"] to exclude all the composed fields or raise ValueError. Raising an error might be wiser?

Failing test:

tests/composite_pk/test_models.py

@@ -118 +118 @@
 
                 self.assertSequenceEqual(ctx.exception.messages, messages)
 
+    def test_clean_fields_exclude_pk(self):
+        post = Token()
+        post.clean_fields(exclude=["pk"])
+
     def test_field_conflicts(self):
         test_cases = (
             ({"pk": (1, 1), "id": 2}, (1, 1)),

======================================================================
ERROR: test_clean_fields_exclude_pk (composite_pk.test_models.CompositePKModelsTests.test_clean_fields_exclude_pk)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/.../django/tests/composite_pk/test_models.py", line 123, in test_clean_fields_exclude_pk
    post.clean_fields(exclude=["pk"])
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/Users/.../django/django/db/models/base.py", line 1708, in clean_fields
    raise ValidationError(errors)
django.core.exceptions.ValidationError: {'tenant': ['This field cannot be null.'], 'id': ['This field cannot be null.']}

----------------------------------------------------------------------

[Sarah Boyce]

I might be misunderstanding but I feel like the current behavior is correct
I think we tried to hint at this in the docs in the ​Composite Primary Keys in forms section. Do you think we need to expand on this or have I misunderstood what you're expecting?

[Jacob Walls]

This might be a nothing, but the doc explains that a "virtual field" is "excluded from model forms" and "does not have a form field", but it doesn't tell me what impact there is on model validation, forms aside. "Virtual field" isn't described elsewhere in the docs, so for me I didn't follow that it couldn't be passed to exclude=.

A model with composite pk's looks like it has a model field called pk, so the idea is a user might think you can pass it to exclude_fields and get every part of the pk excluded. From the linked doc I can't really tell that I can't.

(As I'm sure you've gathered I'm just kicking the tires here. Fine to wait to see if this comes up in practice.)

[Sarah Boyce]

True, a "virtual field" is not really a defined term and in my head things like a ​GenericForeignKey or a ​GeneratedField might be in a similar category.
I will accept as happy to review a docs update

[Jacob Walls]

​PR

[Sarah Boyce <42296566+sarahboyce@…>]

In f0540459:

Refs #36070 -- Referred to pk as an attribute when a composite primary key is defined.

This is to avoid confusion that a field is often associated with having
a single associated database column.

[Sarah Boyce <42296566+sarahboyce@…>]

In de9f46d:

Fixed #36070 -- Clarified model validation behavior for composite pks.