select can do it in “one go” as well.
user |> Ecto.assoc(:chatrooms) |> select([cr], map(cr, [:id, :name])) |> Repo.all()
LostKobrakai
0
silverdr
Yes, as mentioned I used your initial response to create a helper:
def names_and_ids_for_user(user, order_by \\ nil) do
user
|> Ecto.assoc(:chatrooms)
|> select([o], map(o, [:id, :name0]))
|> order_by(^order_by)
|> Repo.all()
end
Which is exactly based on your suggestion. Once more - thank you for your prompt and very helpful responses!
0
sodapopcan
I went a little too far with my answer by extracting it to a function when obviously @LostKobrakai 's a way better version. My point was just that Ecto is much faster than ActiveRecord (when you are creating AR objects) so it’s not the end of the world to grab all the fields but that is really neither here nor there.
Moving on from pluck, from what you wrote I get the impression you haven’t grasped the full power of composability. You certainly shouldn’t be needing to write SQL first to turn it into Ecto with any regularity. I’ve found Ecto to be incredibly concise and I don’t miss AR even a little. A lot of reusable little one line query helpers can go a really long way. I would have to see examples of what you’re doing, though (not suggesting you want to share, of course 
)
1
silverdr
Sure, Ecto is expected to be much faster in given case as it does not need to create large objects in a still relatively slow language/environment. I presume (and hope - although haven’t done any Benchee stuff to prove it) it should be faster even against the pluck option of Rails.
I am not sure what is the meaning of the end of the sentence here (?).
Still I very, very rarely “grab all the fields/columns” when I don’t need them. That’s because I very rarely am fully convinced that the table I grab things from today is not going to expand beyond the realm of what I find “decent” for this approach if not tomorrow then a bit later. Sure, for small projects, low traffic and stuff that is not really meant to be extended that is an absolutely viable way. In more general case OTOH I am much more constrained in my approach choices. Some may call it “premature optimisation”, which it might actually be, but I call it “it doesn’t cost me to do it more performant already from the start”. At least unless it does… 
I can’t be sure how far I am with grasping its full power. I like and use it whenever it makes sense to me. Just don’t really see the point and how it relates to:
The very first example from this very thread
query =
from cr in Chatroom,
join: ucr in assoc(:users_chatrooms),
on: ucr.user_id == ^user_id and ucr.chatroom_id == cr.id,
select: map(cr, [:id, :name])
Repo.all(query)
If that’s not writing SQL in a convoluted (for SQL savvy person) syntax?
And for something that I know can be as simple as user.chatrooms.pluck(:id, :name)
The same for user.chatrooms.count, which is obvious what it does, and I both understand and remember it the moment I see it but had to google the other day how to express this to make Ecto happy. And guess what? The first thing I found was another writing another SQL query in Ecto syntax.
Yes, I know that Ecto is not an ORM, It is closer to Arel for example, on top of which an ORM could be built. Yes, I know there’s also “pipe syntax” which while still far away from the simplicity of the ORM syntax is much more palatable for me. If for one reason then for the fact that it does not resemble SQL so much as to start questioning its added value… even if that’s only for fooling myself
In any case, my problem was swiftly solved by Benjamin and the rest is mostly the result of my personal “love-hate” relationship with Elixir and its libs.
0
LostKobrakai
Ecto only fetches the fields present in the schema anyways. You could even have multiple schemas for a single table, but different use cases. If you’re hardly fetching all fields of a schema I’d wonder if the schema is well defined or if you’d not rather want to split it into multiple.
4
silverdr
Which would make the problem of a) querying unneeded baggage, b) fetching that, and c) plucking required fields from a large record go away indeed. Shall keep that in mind as a good alternative in appropriate cases!
I didn’t say that. It is when I don’t need it, especially in a busy application spot, I don’t want to do all the three things I mentioned above.
0