Intophoenix.io - our how-to site for ASP.NET programmers

Learning Resources Guides/Tuts/Tips/Info
,
7

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

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,…) :slight_smile:

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! :+1:

1 Like