Ecto usage patterns

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.

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.

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 GitHub - edisonywh/condiment: 🍡 Add flavors to your context function without the hassles. · GitHub 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.

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

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 GitHub - Adzz/ecto_morph: morph your Ecto capabilities into the s t r a t o s p h e r e ! · GitHub

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

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.

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?

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.

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.

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.