/eql

Erlang with SQL or not

Primary LanguageErlangMIT LicenseMIT

eql Hex.pm


Erlang with SQL, inspired by yesql.


description

Suppose we have a database with a list of users, in Erlang we can use simple ORM (boss_db, texas), SQL builders (sqerl, mekao) or write SQL queries in Erlang code like this:

get_users(Conn) ->
    pgsql:squery(Conn, "SELECT * FROM users;").

Or something like that. yesql proposes to write SQL queries by your hands, but do it comfortably. Because most of ORM and SQL builders adds some accidental complexity to your software, ORM or builder should parse your code into SQL and then your RDBMS should parse SQL, also write a complex query in ORM - is pure hell, sometimes. That's why you should use pure SQL with some handy features, like that:

-- Get all users from database
-- :get_all_users
SELECT *
FROM users;

-- Just some description here
-- :get_user_by_id
SELECT *
FROM users
WHERE id = ?

-- Just some description here
-- :get_by_id
SELECT *
FROM :table
WHERE id = ?

In Erlang you can use these queries like functions:

> {ok, Queries} = eql:compile("queries/user.sql"). % with path to your queries file
> {ok, Q1} = eql:get_query(get_all_users, Queries).
> {ok, Q2} = proplists:get_value(get_user_by_id, Queries).
> {ok, Q3} = eql:get_query(get_by_id, Queries, [{table, "some_table"}]).
> Q1.
%> <<"SELECT * FROM users;">>
> Q2.
%> <<"SELECT * FROM users WHERE id = ?">>
> Q3.
%> [<<"SELECT * FROM ">>,"some_table",<<" WHERE id = ?">>]

Note: The named parameters like :table in the example above are not sanitized, so can be dangerous.


Not only for SQL

This library can provide anything you want with separated sections in file, eg for ENV-specific configuration:

-- ./env.config file
-- :dev
[{host, "app.dev"}].

-- :prod
[{host, "app.com"}].

We can parse this file like SQL queries (but comments with % isn't supported yet, you can create PR for this feature :)).

> {ok, Config} = eql:compile("./env.config").
%> {ok,[{prod,<<"[{host, \"app.com\"}].">>},
        {dev,<<"[{host, \"app.dev\"}].">>}]}

eql:compile/1 returns proplist of defined env configurations and we can parse each of them with simple helper:

-module(config_helper).
-export([load/2]).

load(Env, Config) ->
    parse(scan(proplists:get_value(Env, Config))).

scan(undefined) ->
    undefined;
scan(IoList) ->
    erl_scan:string(lists:flatten(io_lib:format("~s", [IoList]))).

parse({ok, Tokens, _}) ->
    erl_parse:parse_term(Tokens);
parse(_) ->
    undefined.

And use it like:

> config_helper:load(prod, Config).
%> {ok,[{host,"app.com"}]}
> config_helper:load(dev, Config).
%> {ok,[{host,"app.dev"}]}

This module already exist and named eql_config for you.


Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

If you make changes to the neotoma PEG file, src/eql_parse.peg you must run rebar3 as dev compile to rebuild src/eql_parse.erl, then run rebar3 commands like compile and eunit as normal.