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
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.
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.
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.
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.
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.