Ecto usage patterns

Chat / Discussions
, ,
1

Hi,

My background is many years of ruby development. I was introduced to
Elixir couple of years ago and since then use it very often as it is
“go to” language for all my projects.

One main difference with ruby ecosystem for me is elixir is more
explicit. You have to define aliases, you have to import all required
functions and so on.

Although I like explicitness, I think in some cases it may slow down a
pace. As an example, often you need to check something in a database
in your console.

In order to do that with Ecto, you have do all imports, then you have
to remember all aliases for schemas and namespaces with context names.

I miss the ActiveRecord where you could write
User.last or User.find_by(email: "email").posts.

With Ecto you have to explicitly preload associations, import helper
functions and so on.

I’ve riched the point when I think about writing some wrapper/helper
which will load on console initialization and will define all aliases
in advance and automatically load associations on method calls.

I would like to know am I alone with this need and is it really an
issue. Maybe I need to have more experience with Ecto when I got used
to write all aliases/includes/preload every time I want to hack in a
console.

Thank you for any feedback on this topic.

1 Like
2

Personally I’d evaluate the reasons for “hack(ing) in the console”. If you do the same thing over and over again it should have some proper API to call and if it’s different things all the time I’m wondering why those need to happen in the first place. For just looking at the db state I personally just use a GUI for the db.

2 Likes
3

Not sure how this is related to ecto efficiency…

Anyway, what is requireing you to import or alias? If its just for some onetime thing, why not use the fully qualified module and function names?

Alternatively you could also set up a .iex.exs in your project that does all the preparational imports and aliases for you.

1 Like
4

Don’t think it has anything to do with “Ecto efficiency”.

Automatically preloading association was one of the biggest source of performance issues in Rails with N+1 queries, I am really glad that Ecto does not do that by default, it forces you to understand what exactly your code needs (I love when libraries nudges you to good, explicit/obvious patterns).

Anyway, I do like User.find_by(email: "email") style of code (which you can also use Repo.get_by() btw, but I was missing it for context functions, so I created a small library here https://github.com/edisonywh/condiment that helps make this easier.

EDIT: Like nobbz pointed out as well, you can define a .iex.exs file, on the app level or on the global level, and that saves you a lot of typing too.

3 Likes
5

Thanks for all the feedback, I’ve changed the title to “Ecto usage patterns”.

1 Like
6

Completely agree, I love the explicitness but I do feel like sometimes that you have to jump through a lot of hoops. But I would say don’t be afraid to write higher level abstractions!

I wrote ecto_morph to help with things like that, take a look if you are interested https://github.com/Adzz/ecto_morph

But it would be totally acceptable to create Active Record style helpers if you needed / wanted them in your application.

1 Like
7

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.

8

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 :slight_smile: Have you been using it in prod & have you found any issues?

9

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.

10

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.

11

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.

12

Both variants will do two separate queries.

13

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.

14

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.

15

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.

1 Like
16 
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.

6 Likes