??? You have SQL, which has joins, aggregations, etc. Not every project needs an ORM to simulate “object” coming from the db. Some (think utilities) work perfectly well sending queries to the db and getting back an array of maps.
sribe
LostKobrakai
That’s perfectly in the realm of ecto. It can do quite a lot even without writing a single schema and even schemas are more a typed map than “objects coming from the db”.
1
dimitarvp
What was discussed was “could we not use a DB at all”, which I interpreted as “can’t we just use GenServers / Agents for data storage” – in which case you lose all the benefits that a SQL interface would give you otherwise.
I misunderstood the comments above mine but this is what I was talking about. I see now that people were discussing “SQL without frameworks”. Oh well, my bad.
1
sribe
Megatomix
I’m actually a beginner in development, and I’m, let’s say, lost with so many possible paths, and each path with its pros and cons - and many frameworks that take you to the same destination, so I’ve chosen the most direct path possible, and in my modest opinion, to use things in native language, would be those way!
As I said, I know some things will take longer without using the framework shortcuts, but I bet in the future, knowing how to use the pure concepts of each language will help me better use frameworks when I’m ready for them!
Or not ?
1
AstonJ
If you are a beginner in development I would highly recommend using a framework like Phoenix - it makes a lot of sensible choices for you and so will save you a lot of headache - saving you from having to research all the different paths/approaches etc.
I would ask, why not use a framework? If you don’t have any pressing reasons not to use a framework, I would say use one 
4
tty
It is also easier to go from framework to direct, just treat the framework as a proof-of-concept work. Once you have a stable set of features you can decide if rewriting to direct SQL makes sense.
Often times starting with direct SQL you find yourself adding features until it starts looking like a framework anyway.
0
lud
With Ecto I do just this :
fetch_all(
"""
SELECT name, first_name
FROM users
WHERE category_id = $1
""",
[category_id]
)
defp fetch_all(sql, params \\ []) do
rs = Ecto.Adapters.SQL.query!(Repo, sql, params)
cols = Enum.map(rs.columns, &String.to_atom(&1))
data =
Enum.map(rs.rows, fn row ->
Enum.zip(cols, row) |> Enum.into(%{})
end)
end
defp fech_one(sql, params \\ []) do
case fetch_all(sql, params) do
[result] -> result
_ -> {:error, :not_found}
end
end
It’s far from perfect but it does the job. Beware of String.to_atom
1
peerreynders
The thing is - SQL is native to the RDBMS - not the backend environment.
So you typically end up with repetitive data type conversions SQL <-> native which often leads to an ad hoc framework.
By all means learn SQL first and design your queries SQL first. But once your have those basics down it’s worthwhile to invest some time into something like Programming Ecto just so you don’t have to explicitly deal with even the most basic data type conversions. On top of that you’ll be able to compose dynamic queries much more easily.
Learning and using Ecto without some appreciation for SQL can in some cases be problematic. But once you understand SQL, Ecto can remove some of the annoying, repetitive detail that could otherwise clutter your code.
3