Comment by dugmartin | Hacker News Reader

Comment by dugmartin | Hacker News Reader

I've had an niche event ticketing Elixir/Phoenix app in production for 4 years and have had next to zero problems. It gets very bursty traffic (100s of simultaneous users when an event opens for ticket purchases with load quickly tapering off in a negative exponential distribution) and the load average barely changes with insanely fast responses on a $10 VM.

I think the only downside for me is having to squint sideways to figure out how to convert a complex SQL query into Ecto. I've been writing SQL for almost 30 years and I find myself dropping into using Ecto's `fragment` too often. I've been meaning to pickup "Programming Ecto" to educate myself more (https://pragprog.com/titles/wmecto/programming-ecto/).

I've done my share of RoR apps too and the nice thing about Elixir is there is very little magic and what magic there is (mostly via macros and code auto added via a `use` statement) can be seen and changed directly in your code instead of being hidden in some gem somewhere.

I write very few fragments and many more raw queries. No ORM is worth the trouble of going too deep into the rabbit hole of learning for the nth time how to write SQL in X.

It is tempting to just drop down to raw queries but then when I read about things like composable Ecto queries (https://medium.com/flatiron-labs/how-to-compose-queries-in-e...) it makes me want to stay at the higher abstraction level.

The final example in that post:

    EctoCars.Car 
    |> EctoCars.Car.with_color("blue") 
    |> EctoCars.Car.with_transmission("automatic") 
    |> EctoCars.Car.with_engine_horse_power(200) 
    |> EctoCars.Repo.all()

generates very clean SQL:

    SELECT c0."id", c0."color", c0."vin_number", c0."specification_id"
    FROM "cars" AS c0
    LEFT OUTER JOIN "specifications" AS s1 ON c0."specification_id" = s1."id"
    LEFT OUTER JOIN "transmissions" AS t2 ON s1."transmission_id" = t2."id"
    LEFT OUTER JOIN "engines" AS e3 ON s1."engine_id" = e3."id" 
    WHERE (c0."color" = $1) AND (t2."type" = $2) AND (e3."horse_power" > $3)

Yes, we use that pattern in the Elixir project I'm working on. But that's a simple query despite all the JOINs. It's just a waste of time to convert complex queries into Ecto. Maybe the reason is that I build them in the database using it as a REPL. Then I have working SQL and a lot of hard work to turn them into Elixir. Or Ruby, or Python or whatever. I played that game for far too long. I give up immediately now, write raw SQL and move on to the next productive task.

I think the parent commenter is not saying to write your one time use query in elixir using wrapper modules with Ecto, but tried to show that queries generated by Ecto are pretty clean and understandable in compare to other popular DataMappers/ORMs

That sounds like a fun but challenging project: Convert sql to idomatic ecto. Mostly as a way to help people learn ecto better. Probably a long-tail-y issue, but maybe one where a 70% solution is useful?

Reply on news.ycombinator.com