SQL - Brings an extensible SQL parser and sigil to Elixir, confidently write SQL with automatic parameterized queries.

Your Libraries & OS Mentoring Libraries
, , , , , , ,
21

I even thought about using sigil modifiers, but not sure if that is to abusive


iex(1)> Enum.to_list(~SQL[from users select *]User)

16:31:00.046 [debug] QUERY OK db=0.4ms decode=0.7ms queue=1.6ms
select * from users []
[
  #User<
    __meta__: #Ecto.Schema.Metadata<:built, "users">,
    id: 1,
    name: "john",
    age: 18,
    ...
  >
]
22

I think an SQL + Ecto integration that allows control to which of multiple Repos the Query is send, would be valuable as it allows adopting the SQL + Ecto integration in brownfield projects.

Our use case is a data dashboard that pulls data from multiple, already existing, databases. In such a brownfield context, we find DBAs and peer developers that are not experienced in Elixir/Ecto already, and allowing them to contribute to a project with SQL queries, eliminating the need to translate them to Ecto.Query, would be a real boost and lower the barrier for Elixir adoption.

Your work is very interresting and relevant.

4 Likes
23

Yeah, the simplest approach for that would be to deprecate Repo.query/2 in favor of Repo.query/1.

This would allow any query executed by ecto rather that is an Ecto.Query or SQL to be prepared and optimized by the database.

What is still not all clear is how to upcast and downcast schemas, Ecto use positional references to know which column belongs to which fields or associations to map on the result set.

Today Ecto’s datamapper is entirely tied to Ecto.Query. Decoupling this would allow for better optimization and increase the maintainability of Ecto IMO.