@charettes am I missing something??? 🤯

@nessita There is some context in the attached ticket, but I think it would be valuable to keep the not field.concrete check. In my case, I am subclassing ForeignObject to implement .select_related(...) joins against correlated subqueries, and this would ensure that a FieldError is appropriately raised when calling update against it. I assume this would be helpful for other uses of ForeignObject, where it would not be appropriate to allow an update.

@nessita There is some context in the attached ticket, but I think it would be valuable to keep the not field.concrete check. In my case, I am subclassing ForeignObject to implement .select_related(...) joins against correlated subqueries, and this would ensure that a FieldError is appropriately raised when calling update against it. I assume this would be helpful for other uses of ForeignObject, where it would not be appropriate to allow an update.

Thank you @rpkilby! I did read the ticket, but I still think there are two things in this PR:

1. Boolean logic simplification: direct can be reduced and removed, as mentioned in my previous comment, since we can prove it's equivalent using boolean algebra.
2. Maybe a new feature? The change in add_update_values, based on the new test, looks like it slightly changes the logic consequently changing the current behavior. So I think we need to consider that as well. Could this be seen as a breaking change? (honest question)

Hi @nessita. I'd argue the two items are related and that this is more of a bugfix. imo this change reflects the intent of the original code, and direct being reducable is only due to the faulty logic, which this would fix.

As to the changed test method, composite keys are a new feature as of 5.2, and ForeignObject is documented as being an internal API. I think raising a different exception is reasonably a bugfix. Additionally, .update() isn't tested against a saved instance, which fails with AttributeError: 'ForeignObjectRel' object has no attribute 'get_related_field'. Raising FieldError: Cannot update model field <django.db.models.fields.related.ForeignObject: user> (only non-relations and foreign keys permitted) seems more correct and consistent than the assertion/value errors. That said, I don't know if there are other non-concrete fields that this change would incorrectly impact.

Updated the test to include both saved and unsaved instances.

@charettes should I commit an update with the following changes:

diff --git a/django/db/models/fields/related.py b/django/db/models/fields/related.py
index bad71a5fd6..e97ecf8a0d 100644
--- a/django/db/models/fields/related.py
+++ b/django/db/models/fields/related.py
@@ -1844,6 +1844,10 @@ class ManyToManyField(RelatedField):
             )
         return name, path, args, kwargs
 
+    def get_attname_column(self):
+        attname, column = super().get_attname_column()
+        return attname, None
+
     def _get_path_info(self, direct=False, filtered_relation=None):
         """Called by both direct and indirect m2m traversal."""
         int_model = self.remote_field.through
diff --git a/django/db/models/sql/subqueries.py b/django/db/models/sql/subqueries.py
index d0e0f82cd5..86f12f95ea 100644
--- a/django/db/models/sql/subqueries.py
+++ b/django/db/models/sql/subqueries.py
@@ -91,10 +91,10 @@ class UpdateQuery(Query):
                 raise FieldError(
                     "Composite primary key fields must be updated individually."
                 )
-            if not field.concrete or (field.is_relation and field.many_to_many):
+            if not field.concrete:
                 raise FieldError(
-                    "Cannot update model field %r (only non-relations and "
-                    "foreign keys permitted)." % field
+                    "Cannot update model field %r (only concrete fields are permitted)."
+                    % field
                 )
             if model is not self.get_meta().concrete_model:
                 self.add_related_update(model, field, val)
diff --git a/tests/update/tests.py b/tests/update/tests.py
index bb83440008..e17d906c80 100644
--- a/tests/update/tests.py
+++ b/tests/update/tests.py
@@ -160,7 +160,7 @@ class AdvancedTests(TestCase):
         msg = (
             "Cannot update model field "
             "<django.db.models.fields.related.ManyToManyField: m2m_foo> "
-            "(only non-relations and foreign keys permitted)."
+            "(only concrete fields are permitted)."
         )
         with self.assertRaisesMessage(FieldError, msg):
             Bar.objects.update(m2m_foo="whatever")

@rpkilby no lets keep this work focused on dealing with ForeignObject please. It's possible that implementing ManyToManyField.get_attname_column cause other breakages so it should be investigate separately.

Thanks - let me know if there's anything else I can to do to help wrap this up.

It's possible that implementing ManyToManyField.get_attname_column cause other breakages so it should be investigate separately.

I've reopened https://code.djangoproject.com/ticket/35453, which discusses this question.