Refs #5929 -- Added a CompositeField expression to support multi-column subqueries. by p-r-a-v-i-n · Pull Request #21496 · django/django

p-r-a-v-i-n · 2026-06-16T16:09:14Z

Trac ticket number

Branch description

This PR Introduces a CompositeField to support subqueries which return multi-cols.

Currently Django ORM does not have internal machinery to decide the output_field of subqueries which have multi-columns in their output.

CompositeField will resolve output_field for such subqueries.

Notes about this PR:

Scope of CompositeField for this PR is limited to virtual sources only.
This PR uses TableExpression, Relation, Subquery Class to make CompositeField workable. Later This may be removed or refactored. This is just for organising the code.

References:

AI Assistance Disclosure (REQUIRED)

No AI tools were used in preparing this PR.
I have used Gemini, Chatgpt to write test cases which are mentioned in 30a0e27. i have reviewed this test cases.

Checklist

This PR follows the contribution guidelines.
This PR does not disclose a security vulnerability (see vulnerability reporting).
This PR targets the main branch.
The commit message is written in past tense, mentions the ticket number, and ends with a period (see guidelines).
I have not requested, and will not request, an automated AI review for this PR.
I have checked the "Has patch" ticket flag in the Trac system.
I have added or updated relevant tests.
I have added or updated relevant docs, including release notes if applicable.
I have attached screenshots in both light and dark modes for any UI changes.

…ession.

jacobtylerwalls

Awesome @p-r-a-v-i-n, I'm looking forward to giving this a more substantive review tomorrow! Right now I just have one question for you about the tests.

When the length of the subfield is 1

…in Query.output_field.

jacobtylerwalls

Great stuff, I like how this is getting more and more concise! Left another round of comments.

jacobtylerwalls · 2026-07-06T18:08:08Z

+Using multi-column subqueries
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A ``Subquery`` can also return multiple columns by calling ``values()`` with


Use Sphinx :meth: target for values().

jacobtylerwalls · 2026-07-06T18:09:28Z

+
+A ``Subquery`` can also return multiple columns by calling ``values()`` with
+multiple field names. In this case, the subquery has a ``CompositeField``
+output.


sphinx target here also: output -> :ref: output_field<output-field>

jacobtylerwalls · 2026-07-06T18:14:50Z


 Models
 ~~~~~~
+* Added support for CompositeField. CompositeField allow subqueries to


Good addition, but we still need to clarify the "Limiting a subquery to a single column" part, because it sounds like Subqueries always have to be limited, and this isn't clarified until later.

Something like:

... as the target of an __in lookup that does not expect a CompositeField, explained below (link).

🤔

jacobtylerwalls · 2026-07-06T18:16:42Z

+Using multi-column subqueries
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A ``Subquery`` can also return multiple columns by calling ``values()`` with


Need versionadded:: 6.2 at the top of this section

jacobtylerwalls · 2026-07-06T18:16:59Z


 Models
 ~~~~~~
+* Added support for CompositeField. CompositeField allow subqueries to


Blank line before the first bullet.

jacobtylerwalls · 2026-07-06T18:59:19Z

        if isinstance(self.lhs, ColPairs):
            return repr(self.lhs.field.name)
+        elif hasattr(self.lhs, "output_field") and self.lhs.output_field.is_composite:
+            names = ", ".join(repr(name) for name in self.lhs.output_field.sub_fields)


Django style is to use list comprehensions instead of generators in cases like this (more verbose but micro-optimization)

jacobtylerwalls · 2026-07-06T19:17:45Z

                                f"Cannot select the '{f}' alias. Use annotate() "
                                f"to promote it."
                            )
+                    elif f.split(LOOKUP_SEP, 1)[0] in self.annotations:


Annotations can have __ in them, so I don't think this logic will work (same as above). Let's add a test for an annotation with __ that exercises this. You can look into how this is handled generally.

Yes , it is failing. i found in one place there also the similar logic was used and it was removed in the upstream.

should we stop them from using such alias(__a__b__c__d______e__some=subquery) illegal alias ?
@jacobtylerwalls @LilyFirefly @charettes

Lily , Simon sorry for tagging here.

Ah, I thought we could just piggyback on the support for double-underscores in annotations that we already have, but I forgot you can't use an annotation name to reference related object lookups anyway. For example, after .annotate(foo=F("some_fk")):

you can do foo__isnull

but you cannot do foo__fk_field, you have to do some_fk__fk_field

That makes sense, because the expression might be more complicated than just F.

So we really only support __ in annotation aliases when they're terminal. For this PR's new lookup functionality, we should throw a nice Python exception when it's attempted (either adding the annotation or doing the lookup--not sure), rather than possibly parse __ and chop at the wrong location.

jacobtylerwalls · 2026-07-06T19:34:30Z

+        elif self.values_select and self.select:
+            is_composite = True


If len(self.values_select) == len(self.select) == 1, we don't have a composite field, but we end up going through CompositeField.from_select() anyway. That doesn't seem quite right.

e.g. in test_union_in_subquery():

(Pdb) self.select (Col(queries_number, queries.Number.num),) (Pdb) self.values_select ('num',)

yeah that seems weird, we should not have composite columns when only a single row is selected.

jacobtylerwalls · 2026-07-06T19:36:45Z

    def get_lhs_str(self):
        if isinstance(self.lhs, ColPairs):
            return repr(self.lhs.field.name)
+        elif hasattr(self.lhs, "output_field") and self.lhs.output_field.is_composite:


Remind me why we need the defensive hasattr here and in process_lhs?

jacobtylerwalls · 2026-07-06T19:41:58Z

+            if self.output_field.is_composite and self.output_field.has_one_field:
+                return resolved


This whole outer if branch avoids returning resolved, preferring either resolved.query or ExpressionWrapper(resolved.query, output_field=self.output_field), so at a glance I would expect this new branch to return one of thos two. Can you look at the blame to see what kind of test case we need to support here, and then add that test case?

LilyFirefly

I'm very excited to see this progress! I have a bunch of minor feedback (nitpicks and suggested refactors) and a few deeper questions.

LilyFirefly · 2026-07-06T19:29:17Z

+        if annotation_select:
+            select_map = {}
+            for key, value in annotation_select.items():
+                select_map[key] = extract_field(value)
+
+        if values_select:
+            select_map = {}
+            for path, sel in zip(values_select, select):
+                field = extract_field(sel)
+                select_map[path] = field


This looks odd! If both annotation_select and values_select are truthy, then select_map will only gain entries from values_select. I would expect to see either an exception raised if passing both is invalid, or for select_map to be built using a combination of annotation_select and values_select. If the current logic is intended, I think it needs a comment to explain why.

LilyFirefly · 2026-07-06T19:31:32Z

+            select_map = {}
+            for key, value in annotation_select.items():
+                select_map[key] = extract_field(value)


Nitpick, this could use a dictionary comprehension:

Suggested change

select_map = {}

for key, value in annotation_select.items():

select_map[key] = extract_field(value)

select_map = {key: extract_field(value) for key, value in annotation_select.items()}

LilyFirefly · 2026-07-06T19:33:47Z

+                select_map[path] = field
+        elif annotation_select is None:
+            fields = [extract_field(sel) for sel in select]
+            select_map = {field.name: field for field in fields}


I think we need to check for field being None here:

Suggested change

select_map = {field.name: field for field in fields}

select_map = {field.name: field for field in fields if field}

Possibly raising an exception would be better (it currently does, but we can likely do better than an AttributeError).

LilyFirefly · 2026-07-06T19:35:08Z

+    def _make_composite(cls, name, value):
+        if isinstance(value, dict):
+            sub_fields = {k: cls._make_composite(k, v) for k, v in value.items()}
+            return cls(**sub_fields)
+        return value


This doesn't do anything with the name parameter. If that isn't needed by future (unwritten) code, we can simplify:

Suggested change

def _make_composite(cls, name, value):

if isinstance(value, dict):

sub_fields = {k: cls._make_composite(k, v) for k, v in value.items()}

return cls(**sub_fields)

return value

def _make_composite(cls, value):

if isinstance(value, dict):

sub_fields = {k: cls._make_composite(v) for k, v in value.items()}

return cls(**sub_fields)

return value

LilyFirefly · 2026-07-06T19:36:53Z

+        sub_fields = {k: cls._make_composite(k, v) for k, v in nested.items()}
+        return cls(**sub_fields)


I think this can use _make_composite more directly (with the removal of the name parameter I suggest below):

Suggested change

sub_fields = {k: cls._make_composite(k, v) for k, v in nested.items()}

return cls(**sub_fields)

return cls._make_composite(nested)

LilyFirefly · 2026-07-06T20:06:37Z

    def output_field(self):
-        if len(self.select) == 1:
-            select = self.select[0]


We seem to have lost this logic - was that intentional? I'd expect to see it in the if not is_composite: block below.

LilyFirefly · 2026-07-06T20:07:55Z

-                if item in self.annotations:
+                if (
+                    item in self.annotations
+                    or item.split(LOOKUP_SEP)[0] in self.annotations


Should this use the two-argument form of split, like below?

Suggested change

or item.split(LOOKUP_SEP)[0] in self.annotations

or item.split(LOOKUP_SEP, 1)[0] in self.annotations

LilyFirefly · 2026-07-06T20:11:17Z

+        condition = hasattr(self.output_field, "conditional") and isinstance(
+            self.output_field.conditional, fields.BooleanField
+        )
+        return condition or isinstance(self.output_field, fields.BooleanField)


I think this would be equivalent, but maybe a bit simpler:

Suggested change

condition = hasattr(self.output_field, "conditional") and isinstance(

self.output_field.conditional, fields.BooleanField

)

return condition or isinstance(self.output_field, fields.BooleanField)

return isinstance(self.output_field, fields.BooleanField) or isinstance(

getattr(self.output_field, "conditional", None), fields.BooleanField

)

Or more verbosely:

Suggested change

condition = hasattr(self.output_field, "conditional") and isinstance(

self.output_field.conditional, fields.BooleanField

)

return condition or isinstance(self.output_field, fields.BooleanField)

if isinstance(self.output_field, fields.BooleanField):

return True

conditional = getattr(self.output_field, "conditional", None)

if conditional is None:

return False

return isinstance(conditional, field.BooleanField)

LilyFirefly · 2026-07-06T20:31:10Z

+        return len(self.sub_fields)
+
+    @property
+    def has_one_field(self):


I see a lot of special-casing based on this - I wonder if it would be cleaner to require at least two fields in a CompositeField - I'm hoping we could special-case in a lot fewer places that way.

That was my immediate reaction as well. I don't understand what the benefits of making one member composition of queryset aliases nested.

Isn't it easier to continue to make

Foo.objects.alias( baz=Bar.objects.filter(pk=OuterRef("bar_id")).values("baz") ).filter( baz="value" )

instead of also allowing filter(baz__baz="value") and potentially changing the plan of the generated query to perform a JOIN?

it would be cleaner to require at least two fields in a CompositeField - I'm hoping we could special-case in a lot fewer places that way.

That sound reasonable.

LilyFirefly · 2026-07-06T20:35:07Z

+        inner = CompositeField(email=EmailField(), age=IntegerField())
+        outer = CompositeField(user=inner, title=CharField())


Do we have a use-case for nesting CompositeField? I worry that it will generate a lot of edge-cases we need to handle carefully. If there's no use-case it might be cleaner to forbid it.

@jacobtylerwalls , @charettes @LilyFirefly What's your thought should we allow ? and i agree with your concern. It's better to forbit it at least for now.

Yeah, anything to reduce scope right now is a win.

charettes

Thanks for the work so far @p-r-a-v-i-n, I left a few comments.

charettes · 2026-07-06T20:56:29Z

        return [self]


+class CompositeCol(Expression):


Do we really need this expression or could we do away with using Tuple instead?

I'm fairly confident a ton of complexity can be pruned by making tuple_lookups.Tuple.output_field a CompositeField with the output field of all of its source expressions.

Sorry for taking a bit more time on this! I'm still exploring the Tuple idea, so please forgive me if I missed something, and Please correct my understanding

lets say we have sub = Post.objects.filter(user=OuterRef("pk")).values("title", "body")
and if we do User.objects.alias(posts=sub).values("posts__title") in such this case the outer table don't know about the title column. The outer table will receive a subquery . If i understand correctly .alias(info=subquery), the subquery's columns aren't addressable as Col(alias, field) from the outer query they only exist inside the subquery's scope.

and for info__user__email, to resolve user__email Tuple would need some mechanism to do "info"."user__email" from outer query.

And Tuple worked in case of CompositePrimaryKey bcs there wasn't any scenario where it has to look into subquery. and all column referencing to real models ?

I'm interested in Simon's reply, but I have a feeling we should push harder on the Tuple idea and leave OuterRef support for later.

in such this case the outer table don't know about the title column. The outer table will receive a subquery

From my understanding the outer query has a "posts" entry in its annotations map which points at the resolved sql.Query from sub that has an output_field of

output_field = CompositeField( title=Col("posts", "title", Post._meta.get_field("title")), body=Col("posts", "body", Post._meta.get_field("body")), )

in other words the alias of the Col of its output_field are the alias given to the FROM entry not the one local to the subquery. This binding of outer query alias to the annotation's output_field will likely need to happen at the same time as annotation is added as a member of alias_map.

So to summarize the sequence.

When doing

posts = Post.objects.filter(user=OuterRef("pk")).values("title", "body") users = User.objects.alias(posts=posts)

The users.query.annotations map is augmented with posts.resolve_expression -> sql.Query under "posts".

When posts is first referenced through filter or values (it's not part of alias_map) it gets added to alias_map and through the bounding process the annotation (or the table expression wrapper around it) gets cloned/relabelled so its output field now is aliased to "posts".

charettes · 2026-07-06T20:57:01Z

+            target_field = output_field.related_model._meta.get_field(name)
+            return functools.partial(
+                CompositeCol, lookup_name=name, output_field=target_field
+            )


I think this is too lax as nothing guarantees that the nested subquery has the appropriate JOIN already in place?

e.g. nothing guarantees that the subquery already has JOINed against user when it's aliased?

The subquery is already baked with joins before it touch by CompositeCol. We here just mapping info__user__email to the correct colum of subquery's SELECT list.

for example this example in the case test_composite_nested_lookup_five_levels.

subquery = BugReport.objects.filter( pk=self.bug_report.pk, ).values( "task__name", "task__project__title", "task__project__workspace__name", "task__project__workspace__owner__email", "task__project__workspace__owner__first_name", ) qs = User.objects.alias(ticket=subquery).values( "ticket__task__project__workspace__owner__email", "ticket__task__project__workspace__owner__first_name", )

charettes · 2026-07-06T20:59:56Z

+        elif self.values_select and self.select:
+            is_composite = True


yeah that seems weird, we should not have composite columns when only a single row is selected.

charettes · 2026-07-07T21:43:43Z

-        lhs_is_raster = lookup.lhs.field.geom_type == "RASTER"
+        field = lookup.lhs.output_field
+        if field and field.is_composite and field.has_one_field:
+            field = field.output_field_when_only_one_subfield


Can't say I'm a big fan of these two properties (has_one_field and output_field_when_only_one_subfield).

Why can't we make singleton composite fields behave like non-composite ones?

I agree with you. Honestly my intention was to make it more simple and clean but opposite happened.

charettes · 2026-07-07T21:55:18Z

+    def get_lhs_len(self):
+        if hasattr(self.lhs, "output_field") and self.lhs.output_field.is_composite:
+            return len(self.lhs.output_field)
+        return len(self.lhs)


If we made the lhs a Tuple(Col(...), ...) instead of that CompositeCol I think we'd get that for free.

charettes · 2026-07-07T22:03:07Z

+            CompositeCol(
+                CompositeCol(query, "user", ...),


It seems a bit off that CompositeCol references a sql.Query instance, this will cause problem on cloning (e.g. relabeling) as there is no memoization trough all query objects. In other words the query referenced by the expression and others won't point at the same object on cloning.

May be any failing test case would expose this ? but i'm not able to come up with .
my hypothesis is here.
the root_lhs is always clone before use so it always get fresh clone before .as_sql . so the picture my mind is that bump_prefix is called and all the relabeling done before executing .as_sql.

charettes · 2026-07-07T22:04:59Z

+        parts, root_lhs = self._resolve_lookup_path()
+        full_lookup = LOOKUP_SEP.join(parts)
+        query = root_lhs.clone()
+        query.set_values([full_lookup])


Altering user provided queries could break its semantic.

Think the usage of DISTINCT for example; DISTINCT user.email, title and DISTINCT user.email don't yield the same results.

charettes · 2026-07-07T22:30:21Z

+
+        qs = (
+            User.objects.filter(pk=self.user1.pk)
+            .annotate(post_data=subquery)


Are we planning allow composite expressions to be annotated and not only aliased?

I thought so, do you have a concern about that?

Well it would definitely be interesting to have but I guess it's a bit more work particularly on backends don't support native row/tuple constructs as adding composite primary key support demonstrated.

For example, if you do

books = Book.objects.annotate( author_details=Author.objects.filter( pk=OuterRef("author_id"), ).values("first_name", "last_name") )

I assume users would expect books[0].author_details to be

class AuthorDetails(TypedDict): first_name: str last_name: str

but that poses challenges from a SQL generation perspective as we need to support annotations that spans more that one SELECT fields.

In other words, on backends that natively support tuple constructs we can do

SELECT ..., (author.first_name, author.last_name) author_details FROM book JOIN LATERAL ( SELECT first_name, last_name FROM author WHERE id = book.id ) author

and then CompositeField.from_db_value can unpack the tuple to AuthorDetails but on backends that don't support such construct the tuple must be expanded into multiple aliases

SELECT ..., author.first_name author_details__first_name, author.last_name author_details__last_name FROM book JOIN LATERAL ( SELECT first_name, last_name FROM author WHERE id = book.id ) author

and then sliced, combined together to make their way to from_db_value. Not sure if composite_fields_to_tuples has been adapted to be able to deal with anything but composite primary keys and if it has it certainly didn't to handle for values and values_list variants (e.g. named=True).

Ah. If it reduces scope for other reasons, I might be interested to remove it, but if it just boils down to Oracle versions below 21c, I'm okay not writing any fallback SQL for it and just raising an error. This isn't integral functionality like being able to count primary keys?

github-actions · 2026-07-10T13:46:38Z

Uncovered lines in changed files

-------------
django/contrib/gis/db/backends/postgis/operations.py (0.0%): Missing lines 49-52,103-106
django/contrib/gis/db/models/lookups.py (0.0%): Missing lines 68-71
django/db/models/__init__.py (100%)
django/db/models/expressions.py (100%)
django/db/models/fields/__init__.py (100%)
django/db/models/fields/composite.py (99.0%): Missing lines 225
django/db/models/fields/reverse_related.py (100%)
django/db/models/fields/tuple_lookups.py (100%)
django/db/models/lookups.py (100%)
django/db/models/sql/compiler.py (100%)
django/db/models/sql/datastructures.py (100%)
django/db/models/sql/query.py (100%)
-------------
Total:   262 lines
Missing: 13 lines
Coverage: 95%
-------------

Note: Missing lines are warnings only. Some database-specific lines may not be measured. More information

jacobtylerwalls · 2026-07-10T14:21:31Z

        self.assertNotIn('"info"', sql)
        self.assertNotIn("`info`", sql)

+    def test_composite_test_annotations(self):


This test passes without the bc7fd5d changes. I think we don't need bc7fd5d, see #21496 (comment).

This test was redudant (intention was to check nothing break when normal alias used) I will chop this one but the tests test_composite_test_terrible_alias and test_composite_outer_order_by will fail.

Right, I think both tests should be changed to assert that an exception is raised, see my comment.

jacobtylerwalls

Hey, I just left a few cosmetic comments before I lose track of them.

The more important pending points are removing the new changes in bc7fd5d, and exploring the Tuple idea and other related ideas from Lily & Simon's reviews.

jacobtylerwalls · 2026-07-10T19:18:18Z

+    def get_lookup(self, lookup_name):
+        return super().get_lookup(lookup_name)


jacobtylerwalls · 2026-07-10T19:20:19Z

+expressions in the same way as model fields.
+
+A multi-column ``Subquery`` can also be compared as a whole using tuple
+lookups, for example ``__lt``, ``__in``, and ``__gt``.


Use the markup:

:lookup:`lt`, :lookup:`gt`

etc

jacobtylerwalls · 2026-07-10T19:21:40Z

+class AbstractUser(models.Model):
+    email = models.EmailField(unique=True)
+    first_name = models.CharField(max_length=100)
+    age = models.IntegerField(default=24)
+
+    class Meta:
+        abstract = True
+
+
+class User(AbstractUser):
+    pass


Can we just reuse the django.contrib.auth.models.User? Many other tests do this.

jacobtylerwalls · 2026-07-10T19:22:54Z

-        return connection.ops.get_geom_placeholder_sql(
-            self.lhs.output_field, rhs, compiler
-        )
+        field = self.lhs.output_field
+        return connection.ops.get_geom_placeholder_sql(field, rhs, compiler)


Can be reverted.

jacobtylerwalls · 2026-07-10T19:23:49Z

-        if lookup.lhs.output_field.geography and not self.geography:
+        field = lookup.lhs.output_field
+        if field.geography and not self.geography:


Can be reverted.

jacobtylerwalls · 2026-07-10T19:25:43Z

+            .annotate(the_email=F("info"))
+            .values("the_email")
+        )
+        self.assertEqual(len(list(qs)), 3)


Suggested change

self.assertEqual(len(list(qs)), 3)

self.assertEqual(len(qs), 3)

jacobtylerwalls · 2026-07-10T19:29:04Z

+        with self.assertRaisesMessage(
+            ValueError, "'gt' lookup of ('id', 'email') must be a tuple or a list"
+        ):
+            list(User.objects.alias(info=subquery).filter(info__gt=5))


We don't have to evaluate the qs to get the error. Also, we try to single-line these messages when we can.

Suggested change

with self.assertRaisesMessage(

ValueError, "'gt' lookup of ('id', 'email') must be a tuple or a list"

):

list(User.objects.alias(info=subquery).filter(info__gt=5))

msg = "'gt' lookup of ('id', 'email') must be a tuple or a list"

with self.assertRaisesMessage(ValueError, msg):

User.objects.alias(info=subquery).filter(info__gt=5)

jacobtylerwalls · 2026-07-10T19:29:53Z

+            list(User.objects.alias(info=subquery).filter(info__gt=5))
+
+
+class SingleColumnValuesSubqueryTests(TestCaseSetup):


Curious about the separate class here.

jacobtylerwalls · 2026-07-10T19:30:17Z

+        lhs_field = self.lhs._output_field_or_none
+        rhs_field = self.rhs._output_field_or_none
        combined_type = _resolve_combined_type(
            self.connector,
-            type(self.lhs._output_field_or_none),
-            type(self.rhs._output_field_or_none),
+            type(lhs_field),
+            type(rhs_field),


This can be reverted.

This reverts commit bc7fd5d.

p-r-a-v-i-n · 2026-07-17T08:16:52Z

closing in favour of #21636

p-r-a-v-i-n added 8 commits June 7, 2026 15:15

Refactored BaseTable and Join datastructures to be subclasses of Expr…

1f225fd

…ession.

Experimenting rough approach of CompositeField

000b28f

Validate nested composite field support and formated the code.

532c4d1

Removed the sql/Query.output_field and add some extra tests

4b408ac

Added more tests and organised Relation

a5b7438

Added tests to check the working under difficult queries.

30a0e27

Added support for bare queryset

5bb9120

Added release note and removed comments.

6dc99a4

p-r-a-v-i-n commented Jun 16, 2026

View reviewed changes

Comment thread django/db/models/expressions.py Outdated

p-r-a-v-i-n marked this pull request as draft June 16, 2026 16:15

p-r-a-v-i-n closed this Jun 16, 2026

p-r-a-v-i-n added 2 commits June 17, 2026 13:00

Fixed mysql, mariadb, postgres error

e415916

Replaced , with CROSS JOIN to support in all databases.

155862b

p-r-a-v-i-n commented Jun 17, 2026

View reviewed changes

Comment thread docs/releases/6.2.txt Outdated

p-r-a-v-i-n reopened this Jun 17, 2026

p-r-a-v-i-n force-pushed the composite-field-support branch from e8906a6 to f3cd27d Compare June 17, 2026 09:40

Added lookups support for CompositeField

cb6cd08

p-r-a-v-i-n force-pushed the composite-field-support branch from f3cd27d to cb6cd08 Compare June 17, 2026 10:09

p-r-a-v-i-n marked this pull request as ready for review June 17, 2026 13:29

Updated release note

eccb7c2

p-r-a-v-i-n force-pushed the composite-field-support branch from 8ab4a57 to eccb7c2 Compare June 17, 2026 13:42

jacobtylerwalls reviewed Jun 17, 2026

View reviewed changes

Comment thread tests/composite_field/expressions.py Outdated

Comment thread tests/composite_field/test_composite_field.py Outdated

p-r-a-v-i-n requested a review from jacobtylerwalls June 18, 2026 15:46

jacobtylerwalls reviewed Jun 18, 2026

View reviewed changes

Comment thread tests/composite_field/test_composite_field.py Outdated

p-r-a-v-i-n force-pushed the composite-field-support branch from 11d8aa7 to f5565ad Compare June 18, 2026 17:12

p-r-a-v-i-n added 5 commits June 18, 2026 22:50

Removed explicit wrapping of Subquery and CompositeField

5249c77

Handled scenario when there is foreinkey lookups.

24d4269

Handled scenario when compositeField compiled as scaler.

1aa1788

When the length of the subfield is 1

Stopped removing annotation when compositefield is single scaler.

9c877a0

Fixed single-column values() subqueries to resolve as CompositeField …

7ed61b9

…in Query.output_field.

p-r-a-v-i-n added 2 commits June 23, 2026 15:38

Added len(self.annotataion_select) > 1 check.

751e7e6

Added is_composite to Field class and Refactored

3d7efbe

jacobtylerwalls mentioned this pull request Jun 24, 2026

Add support for table-valued expressions in ORM django/deps#113

Merged

jacobtylerwalls reviewed Jun 25, 2026

View reviewed changes

Comment thread tests/composite_field/test_composite_field.py Outdated

p-r-a-v-i-n added 2 commits June 27, 2026 21:16

Added in-place suggestions

c0685a6

Reverted add_annotation work

ff54275

p-r-a-v-i-n force-pushed the composite-field-support branch from 1015476 to 0e27eb4 Compare June 29, 2026 08:48

Improved coverage and some cleanup

f14dab0

p-r-a-v-i-n force-pushed the composite-field-support branch from 0e27eb4 to f14dab0 Compare June 29, 2026 09:23

Added CompositeCol

a28e36b

p-r-a-v-i-n force-pushed the composite-field-support branch from 2312686 to a28e36b Compare June 30, 2026 10:06

Added docs for multi-column subqueries

3efd805

LilyFirefly self-requested a review July 6, 2026 19:23

jacobtylerwalls reviewed Jul 6, 2026

View reviewed changes

LilyFirefly reviewed Jul 6, 2026

View reviewed changes

charettes reviewed Jul 7, 2026

View reviewed changes

p-r-a-v-i-n added 3 commits July 8, 2026 14:20

Added test distinct in subquery.

23c1f6f

Parsing aliases better when multi-columns used in subqueries.

bc7fd5d

Was forgot to add in the mask. Now fixed.

dd10e75

jacobtylerwalls reviewed Jul 10, 2026

View reviewed changes

p-r-a-v-i-n added 4 commits July 10, 2026 23:21

Refactored CompositeField and from_select and some cleanups.

c7e2d98

Tests for CompositeField forming inside .from_select method

f51e581

Handled when Subquery passed into Compositecol

f96c1d6

Removed checking type output_field for composite

4479602

jacobtylerwalls reviewed Jul 10, 2026

View reviewed changes

Revert "Parsing aliases better when multi-columns used in subqueries."

c80f526

This reverts commit bc7fd5d.

p-r-a-v-i-n mentioned this pull request Jul 17, 2026

Fixed #37115, Refs #5929 -- Added a CompositeField expression to support multi-column subqueries. #21636

Open

7 of 11 tasks

p-r-a-v-i-n closed this Jul 17, 2026

		if self.output_field.is_composite and self.output_field.has_one_field:
		return resolved

	select_map = {field.name: field for field in fields}
	select_map = {field.name: field for field in fields if field}

		sub_fields = {k: cls._make_composite(k, v) for k, v in nested.items()}
		return cls(**sub_fields)

	sub_fields = {k: cls._make_composite(k, v) for k, v in nested.items()}
	return cls(**sub_fields)
	return cls._make_composite(nested)

	or item.split(LOOKUP_SEP)[0] in self.annotations
	or item.split(LOOKUP_SEP, 1)[0] in self.annotations

-        condition = hasattr(self.output_field, "conditional") and isinstance(
-            self.output_field.conditional, fields.BooleanField
-        )
-        return condition or isinstance(self.output_field, fields.BooleanField)
+        if isinstance(self.output_field, fields.BooleanField):
+            return True
+        conditional = getattr(self.output_field, "conditional", None)
+        if conditional is None:
+            return False
+        return isinstance(conditional, field.BooleanField)

		inner = CompositeField(email=EmailField(), age=IntegerField())
		outer = CompositeField(user=inner, title=CharField())

		def get_lookup(self, lookup_name):
		return super().get_lookup(lookup_name)

	self.assertEqual(len(list(qs)), 3)
	self.assertEqual(len(qs), 3)

		list(User.objects.alias(info=subquery).filter(info__gt=5))


		class SingleColumnValuesSubqueryTests(TestCaseSetup):

Conversation

p-r-a-v-i-n commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Trac ticket number

Branch description

AI Assistance Disclosure (REQUIRED)

Checklist

Uh oh!

Uh oh!

Uh oh!

jacobtylerwalls left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jacobtylerwalls left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

p-r-a-v-i-n Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacobtylerwalls Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LilyFirefly left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

p-r-a-v-i-n commented Jun 16, 2026 •

edited

Loading

p-r-a-v-i-n Jul 9, 2026 •

edited

Loading

jacobtylerwalls Jul 10, 2026 •

edited

Loading

charettes Jul 10, 2026 •

edited

Loading