Ecto usage patterns

defmodule MyApp.Explore do
  defmacro __using__(_) do
    quote do
      alias App.Repo
      alias App.UserContext.User
      import Ecto.Query
    end
  end
end

and then you only need to call use MyApp.Explore whenever you need to do something with your data.

That’s what we are telling you though, you can have an .iex.exs that gets automatically loaded into your IEx sessions, so you don’t need to retype them every time.

Well, to be more precise, here is full example what I need to type every time I launch new session in order to achieve something similar to ActiveRecord

alias App.Repo
alias App.UserContext.User
import Ecto.Query

User |> where(email: "email") |> preload(:posts) |> Repo.one()

and I need to do it every time I want to work with a data. If I want to explore Post I have to write one more alias, every time I start new session.

Compare it to User.find_by(email: "email").posts and it’s just a short example. In real world it quickly adds up.

User.admin.first.posts.active.published.update_all(published: false)

Imagine how much typing required with Ecto. You have to alias: User, UserContext, Post, PostContext. You have to quickly remember context names as well for a schemas.

It requires lots of effort to write something quickly in console.

On the other hand, in a project code it really isn’t an issue, because you can write much faster with code editor and most aliases are already here. Also, you need to write custom queries much less often than when you’re hacking in a console.

To nitpick, this isn’t quite the same thing - this returns a User with posts preloaded, the other returns a list of Posts.

To nitpick moar, this does the same number of queries - Ecto does the preloads separately unless the query requires them to be done together explicitly with [posts: p] and a join.

Also beware blindly optimizing for “number of queries” - forcing a single query could be expensive if there are many posts and User is a wide schema, since it will include the user columns in every result row.

Both variants will do two separate queries.

Well, in this case I would prefer:

User |> where(email: "email") |> preload(:posts) |> Repo.one()

As it can reduce amount of queries and round trips.

It’s definitely possible to write these in comparably-short ways, once you’ve done import Ecto.Query:

User |> order_by(desc: :id) |> limit(1) |> Repo.one()

and

Repo.get_by(User, email: "email") |> Ecto.assoc(:posts) |> Repo.all()

These assume you have your schema and repo aliased in, but that isn’t required - full names will work just as well.

Exactly this implementation - no, it is in our todo list. In production, we use simplified version of it. Composite is an enhanced version after real production experience and a lot of local code reviews.

Oh hey that’s really similar indeed! I haven’t seen your library anywhere, the only similar ones I’ve found were TokenOperator & QueryBuilder.

That’s pretty cool! Good sign that the idea isn’t entirely out of whack Have you been using it in prod & have you found any issues?

Wow, I created a library with very similar API called Composite (Composite - a library for writing dynamic queries) which allows to handle a lot of complex cases.