Skip to content

support selecting a subset of a subquery as a struct#4678

Merged
greg-rychlewski merged 3 commits intoelixir-ecto:masterfrom
zachdaniel:subquery-struct-subset-select
Nov 8, 2025
Merged

support selecting a subset of a subquery as a struct#4678
greg-rychlewski merged 3 commits intoelixir-ecto:masterfrom
zachdaniel:subquery-struct-subset-select

Conversation

@zachdaniel
Copy link
Contributor

@zachdaniel zachdaniel commented Nov 8, 2025

This increases the general flexibility of subquery selecting. For example, there might be a case where you want to do something like this:

sub = from post in Post, select: post

from post in subquery(sub),
  where: post.special,
  select: struct(post, [:id, :name])

The special field being filtered outside of the subquery requires selecting it from the subquery, but it doesn't need to be present in the response.

That's a contrived example because you would just filter in the subquery, but real life has gotten me to this point in a more complicated scenario 😄

@zachdaniel
Copy link
Contributor Author

I don't think that integration test is failing due to my changes but there is something weird w/ the results, I can't see them or rerun the task.

@zachdaniel
Copy link
Contributor Author

Feel free to squash.

@zachdaniel zachdaniel force-pushed the subquery-struct-subset-select branch from 74aa800 to b6d7b9b Compare November 8, 2025 15:12
@zachdaniel
Copy link
Contributor Author

Should be good to go 😄

@josevalim
Copy link
Member

One last nitpick and we can ship!

end

defp handle_subquery_struct(select, requested_fields, ix, query) do
available_fields = subquery_source_fields(select)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not able to check atm but I believe error! prints the query so it might be unnecessary to include this in the message

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 I don't think I'm currently adding the query to any error message, but maybe I'm missing it. Could you point out the line?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh sorry I meant that available_fields is only used here:

error!(query, "field `#{field}` in struct/2 is not available in the subquery. " <>
                         "Subquery only returns fields: #{inspect(available_fields)}")

and i think it might be unnecessary because the error! function already prints the entire query. it raises Ecto.QueryError which takes care of it. so you are already told which fields exist in that way.

it's not a big deal either way it was just a tiny cleanup (if my assumptions are right)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, gotcha. I think I'd prefer this because when the query gets big (like in my current case) or involves multiple subqueries for example, it's not always entirely obvious. Listing the available fields I think will make it much clearer.

@zachdaniel
Copy link
Contributor Author

Done 🥳

@greg-rychlewski greg-rychlewski merged commit 0123f91 into elixir-ecto:master Nov 8, 2025
7 checks passed
@greg-rychlewski
Copy link
Member

thanks!

@zachdaniel
Copy link
Contributor Author

🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants