That’s a good idea. There should be an installation guide. I’m not sure if you mean for production or for development but we are still looking for “best” IDE.

I tried to use RubyMine but now I’m using IntelliJ. I was missing some keybinding options in RubyMine. But we also use VS Code and Spacemacs, although that is for nerds .

To programming in Ecto. I’m simply no fan of code-first approach. It’s the same story as with Entity Framework. It’s based on the idea that anyone can create databases without the knowledge of their inner workings. While this is true for Ecto and Entity Framework, it truly creates databases on it’s own, the only way how can they achieve this possibility for so many different database engines is to be quite general. So you have this huge powerhouse named Postgres at your disposal and you use like 10-20% of it’s power just because you don’t have to use SQL.

Look for example at this article.
Why would anyone think that the code below is better than to have a stored procedure/function and make a simple call to it.

articles = Repo.all(
  from c in "articles",
    join: sq in fragment("(SELECT ts_rewrite(plainto_tsquery(?), 'SELECT * FROM aliases') search_query)", ^term),
    on: fragment("search_vector @@ ?", sq.search_query),
    where: not is_nil(c.publish_at)  and c.static == false,
    order_by: fragment("rank DESC"),
    select: %{
      id: c.id, title: c.title, slug: c.slug, display_date: c.display_date, 
      rank: fragment("ts_rank_cd(search_vector, ?, 32) AS rank", sq.search_query),
      introduction: fragment("ts_headline('english',CONCAT(introduction,' ',main_body), search_query, 'StartSel=<mark>,StopSel=</mark>,MinWords=50,MaxWords=100') AS headline"),
      tags: c.tags
    })

But there are other reasons I don’t like this approach as well. For decades we were taught to separate our concerns, to have system boundaries that just have public interfaces and so we created stored procedures, precompiled pieces of database code, and we’ve been calling them. Database owners could rework whole database without us knowing and even care but then Linq to SQL and Hibernate came and told us we should not separate concerns anymore and instead lock our databases in application code.
So now when you want to update simple thing in database you have to redeploy your whole application. That simply cannot be better.

And the last point, one of the benefits of using Ecto or EF or what have you is that you can switch your database at anytime. You can use MS SQL today, Postgres tomorrow and mysql the day after but in my 15 years of professional programming I don’t remember any project that would do that. And I have been to plenty. I’m not saying it’s not happening but how often it actually does? Is this really a valid point?

I’ve just remember one more thing, rollbacks in migration scripts. With ever increasing pressure to go full CI/CD and can easily imagine a situation in which someone who is not familiar with how things work just go to his CI/CD tool and presses “Rollback to version” button and his CD will truly rollback to some previous version of an application without any problem. Everybody is cheering and happy to the moment they realise rollback also meant to remove tables in their database.

So we will cover usage of Ecto in all ways in https://intophoenix.io but internally try to have as many stored procedures as possible.

P.S.: I was one of the people who believed it’s a good thing to use EF but then I realised it’s actually a false marketing and they are dragging me down because I’m unable to change anything without a full migration of my application.

A ano, je milé vidět, že nejsme v tom Elixírovém boji osamoceni na českém poli. Budu se snažit dostat Elixir/Phoenix do České pojišťovny. Je to takový muj vnitřní cíl.

So many hours wasted using NHibernate and now some with Entity Framework Core. Quite likely going back using Dapper and good old SQL. Having ability to design your queries in SQL is golden and you don’t have to on mercy of some SQL translation layer that could cause slow queries that are hard to fix. If you can even fix them without raw SQL.

It can be write for both cases I use to VS Code and I’m satisfied with him. I thought that vim is for nerds

I get your point. But in general, there are different syntaxes between these database engines. So after all then you have to rewrite sql code too. I don’t say that to rewrite all, but somewhere do.

I’m not sure, if it’s good example of Ecto using. As author of this example said two years ago:
“Just try working with it directly in a pg console or sql editor. … I’m trying to find some time over the next couple of weeks to upgrade to Elixir 1.5 and Phoenix 1.3, set things up properly with contexts,…”

I think an important thing here is the context. And also pity that the author hasn’t released the codes yet. Because via context you can establish, for example CRUD implementation. Then you can do it as in our case read_patient.ex e.g.

...
@spec all() :: [Patient.t()]
  def all() do
    Patient.all()
    |> Patient.ordered_by_surname_and_name(:asc)
    |> Patient.ordered_visitations_by_date()
    |> Repo.all()
  end

  @spec search(String.t()) :: [Patient.t()]
  def search(query) when is_binary(query) do
    query
    |> sanitize()
    |> add_prefix_and_suffix()
    |> Patient.search()
    |> Patient.ordered_by_surname_and_name(:asc)
    |> Patient.ordered_visitations_by_date()
    |> Repo.all()
  end
...

where for instance

  @spec ordered_visitations_by_date(Query.t()) :: Query.t()
  def ordered_visitations_by_date(%Query{} = query) do
    v_query = from(v in Visit, order_by: [asc: v.date])
    preload(query, visitations: ^v_query)
  end

So his context could be in this spirit (more readable, more reusable functions,…)

I think the Ecto migrations can help to save a lot of nerves. As it’s mentioned at Ecto book:

Migrations solve an age-old problem: keeping the structure of the database
in sync between production systems, staging systems, and the local systems
running on each developer’s computer. This used to be a manual process and
it was prone to error. A hot fix made on a production system might not
propagate back to the developer’s systems, leading to errors that were hard
to track down. Migrations help automate this process and provide a consistent
framework for making changes across all the systems in your organization.
When adding a new feature that requires changes to the database, you write
a migration: a single Elixir module that can execute the changes you want to
make. You store that migration in source control along with the rest of your
code. When you run the migration on a particular database instance, Ecto
makes the changes specified in your migration to that database, and keeps
track of which migrations have already been run.

Wow tak to drzim palce at to vyjde!