#36431: values() query on ForeignObject discards additional columns
-------------------------------------+-------------------------------------
Reporter: Jacob Walls | Owner: (none)
Type: Bug | Status: new
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: composite primary | Triage Stage: Accepted
key |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* cc: Simon Charette (added)
Comment:
On interesting dilemma we'll have to figure out here is what exactly to
return when a foreign object composed of more than one `from_fields` is
selected through `values` and `values_list`.
With composite primary keys we've made usages of `values("pk")` turned
into `values(Tuple(*pk_field_attnames))` and not
`values(*pk_field_attnames)` so we should be coherent here IMO which means
that we likely want something like
{{{#!diff
diff --git a/tests/composite_pk/test_values.py
b/tests/composite_pk/test_values.py
index 03a9a85496..cc45db40bc 100644
--- a/tests/composite_pk/test_values.py
+++ b/tests/composite_pk/test_values.py
@@ -3,7 +3,7 @@
from django.test import TestCase
-from .models import Post, Tenant, User
+from .models import Comment, Post, Tenant, User
class CompositePKValuesTests(TestCase):
@@ -210,3 +210,9 @@ def test_values(self):
{"pk": self.user_3.pk, "id": self.user_3.id},
),
)
+
+ def test_foreign_object_values(self):
+ Comment.objects.create(id=1, user=self.user_1, integer=42)
+ values = list(Comment.objects.values("user", "integer"))
+ self.assertEqual(values[0]["user"], (self.user_1.tenant_id,
self.user_1.id))
+ self.assertEqual(values[0]["integer"], 42)
}}}
In other words I suggest we double down on making sure references to
composite fields (the only two we support today is composite pk and
foreign objects with multiple fields) in `values` and `values_list` return
tuples instead of flattening them as we've taken this approach for
`CompositePrimaryKey` (which is now part of the public API) and that
`ForeignObject` is still private and has been broken since its
introduction in this regard.
--
Ticket URL: <https://code.djangoproject.com/ticket/36431#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019736903828-9310793d-d4af-4c14-8871-6f4f4abf8598-000000%40eu-central-1.amazonses.com.