alaister

alaister

Hi,
I have the following ecto query:
post_query = from p in Post, where: p.id == ^id, join: c in assoc(p, :comments), join: u in assoc(c, :user), preload: [comments: {c, :user}]

How do I select the following fields: p.title, p.content, p.comments, c.comment, c.inserted_at and u.name?
I’m having trouble with this because of the wired joins I’m doing (Still learning). Also this query actually runs two queries on the database. Is there any way to do it all in one?

Thanks,
Alaister

Showing Posts 1 to 10

Molly101

Molly101

You can use a pattern matching here to get only those fields You’re interested in, i.e. %{title: title, content:content, comments: comments, user: %{name: name}} = Repo.get!(post_query) and then You can pass comments though Enum.Map. In Phoenix app You can also use View - “show.json” approach to convert result of Your ECTO query to a Map with the fields that You need… Because anyway You can’t just encode ECTO query result to JSON…

Linuus

Linuus

This should make only one DB query.

post_query = 
  from p in Post,
    where: p.id == ^id,
    join: c in assoc(p, :comments),
    join: u in assoc(c, :user), 
    preload: [comments: {c, user: u}]

Regarding selecting association fields, you can do something like this (not tested)

post_query = 
  from p in Post,
    where: p.id == ^id,
    join: c in assoc(p, :comments),
    join: u in assoc(c, :user), 
    select: %{id: p.id, title: p.title, comments: p.comments, name: u.name}

Not sure exactly what you want to get back but that’s one way to select fields :slight_smile:

alaister

alaister OP

Thank you @Linuus! I was missing the user: u on the end there. Still not entirely sure what that is doing?

Also the data structure I’m trying to achieve looks like the following:

%{
  content: "This is some content",
  id: "46b7e047-a1f1-4fe1-b7f1-91c2aeb5910d",
  inserted_at: #Ecto.DateTime<2016-06-29 11:49:53>,
  title: "This is a new post"
  comments: [%{
    comment: "Some comment!",
    id: "a94fc738-69e0-44e1-9e39-3204ad7f3878",
    inserted_at: #Ecto.DateTime<2016-07-01 22:48:41>,
    user: %{
      name: "Alaister Young",
    },
    %{
      comment: "Some comment!",
      id: "a94fc738-69e0-44e1-9e39-3204ad7f3879",
      inserted_at: #Ecto.DateTime<2016-07-01 22:48:42>,
      user: %{
        name: "Alaister Young",
      }
    }
  ]
}

The problem I’m having with this structure is I’m not sure how to deal with the list of comments with the nested users.

Thanks again!

Linuus

Linuus

The user: u tells ecto to use that join thingy for the preload and not issue another request to fetch that association. (I think… I’m quite new to Ecto myself.)

So this query:

post_query = 
  from p in Post,
    where: p.id == ^id,
    join: c in assoc(p, :comments),
    join: u in assoc(c, :user), 
    preload: [comments: {c, user: u}]

returns that structure, right? So what you want to do now is limit the number of selected fields for performance reasons?

alaister

alaister OP

That is completely correct!

Linuus

Linuus

I had a discussion about this on IRC and it seems to often be better to not join manually and just preload the data (and let it do multiple queries).

This would issue one request to the DB:

post_query = 
  from p in Post,
    where: p.id == ^id,
    join: c in assoc(p, :comments),
    join: u in assoc(c, :user), 
    preload: [comments: {c, user: u}]

But it would return a lot of excessive data because the join would cause the Post data to be sent for each comment (due to how SQL works). Ecto hides this though by throwing away the excessive data.
You can se this if you run something like the query I wrote before:

post_query = 
  from p in Post,
    where: p.id == ^id,
    join: c in assoc(p, :comments),
    select: %{id: p.id, comments: c}

It will return one struct for each Comment so if a Post has two comments:

[%{
  id: 1,
  comments: %{id: 123, text: "foo"}
}, %{
  id: 1, 
  comments: %{id: 124, text: "Next comment"}
}]`

You don’t see this behaviour when running without the select statement because Ecto takes care of mapping the data.

When just preloading:

post_query = 
  from p in Post,
    where: p.id == ^id,
    preload: [comments: [:user]]

This would issue three requests but no excessive data so in many cases it is actually more efficient (Ecto even does the requests in parallell when possible).
For example, if the same user has made all the comments, the user would only be fetched once. When joining, the user would be returned for each comment.

So, unless you know you have a bottleneck here it may not be worth it…

(I’m quite new to Ecto, so if someone sees something wrong here, please let me know! :slight_smile: )

alaister

alaister OP

Ahh okay that makes a lot of sense! Thanks again :slight_smile:

My only question now is a much more general Ecto question and that’s how to order the comments in descending order. I understand that it has something to do with order_by: [desc: c.inserted_at] but I’m not sure where to put this!

Thanks,
Alaister

alaister

alaister OP

I think I have solved this one:

comment_query = from c in Comment,
                order_by: [desc: c.inserted_at],
                preload: :user

post_query = from p in Post,
             where: p.id == ^id,
             preload: [comments: ^comment_query]

post = Repo.one(post_query)

Also would selecting only the fields I needed make my queries more performant? If so how might I do it with the preloaded users without the join?

Thanks,
Alaister

shahryarjb

shahryarjb

Hello, I have a problem when I want to use select in preload, please see this code

query = from u in UserSchema,
       where: u.id == ^id,
       left_join: c in assoc(u, :subscribers),
       preload: [subscribers: c],
       select: %{
         id: u.id,
         name: u.name,
         mobile: u.mobile,
         last_name: u.last_name,
         mobile: u.mobile,
         status: u.status,
         role: u.role,
         inserted_at: u.inserted_at,
         updated_at: u.updated_at,
         subscribers: c
       }
   Repo.one(query)
  end

and error:

** (Ecto.QueryError) the binding used in `from` must be selected in `select` when using `preload` in query:

I should use select on UserSchema, how can I fix this ?

benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe
query = from u in UserSchema,
       where: u.id == ^id,
       left_join: c in assoc(u, :subscribers),
       preload: [subscribers: c]

   Repo.one(query)

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
kpanic
Hi everyone, I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding. I sta...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
asweet-confluent
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
ryanwinchester
apply_graft/2 doesn’t rewrite an add_many sub-workflow’s deps on an add step. Grafted jobs cancel with “upstream job was deleted” Version...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

Latest on Elixir Forum

Elixir Forum

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews