I have a classic nested comment schema where only one level of children is needed. schema "comments" do field(:message, :string) field(:removed_at, :utc_datetime) belongs_to(:post, Post) belongs_to(:user, User) belongs_to(:parent, Comment) has_many(:children, Comment, for…

Have you considered creating a separate schema for child comments on the same table which doesn’t define the has_many :children? Then you can move the belongs_to :parent over to it and derive each one separately without mapping to ignore irrelevant keys for each context.

[image] seanyutah: The structure being returned looks great and all the data I need is there. But now I would like to pare down that data by selecting only what I need. As a comment about your current queries, I don’t think preloading with joins is the right call here. If a user makes 3 comme…

Thanks for the reply, Ben. That’s interesting that the separate user queries would be faster than the joins. If the users are different for every comment (which will be typical) and I can select for specific user columns in the two joined queries, I’d imagine the joins would be faster, and leave les…

[image] seanyutah: With the issue being that I can’t choose to encode or select the :children from the Comment struct at the top level but also omit it when nested. Oh, I think this is just a misunderstanding about best practices then for JSON encoding. It is NOT considered a best practice to…

Yea it makes sense that using @derive isn’t a best practice. I’m seeing the limitations first-hand. I looked into Phoenix views and didn’t see anything that would allow me to get what I want without nested loops. Do you know of anything? Can you agree that it would be nice to specify/select the chil…

[image] seanyutah: Can you agree that it would be nice to specify/select the children for the top level and omit it from the nested comments, therefore avoiding the need to loop? Isn’t that what my example did? I built a query that selected values on comments, and then reused that at both lev…

Your code outputs the same ecto structure as mine in that the top-level comments have children preloaded and the nested comments do not . Like I said, the ecto output isn’t the problem. The issue I’m wondering about is converting the ecto structs to maps (and then json) without having to map over th…

[image] seanyutah: The issue I’m wondering about is converting the ecto structs to maps (and then json) without having to map over the top level and nested lists. The normal thing is to map over them.

Boom! That is a great idea. Thanks Juan!

Select fields from nested preload query

Questions & Help Questions

benwilson512 April 30, 2022, 2:56am 8

The normal thing is to map over them.