4 ms·

Heh. Recently I had to stand up a quick elixir project and decided to write all queries by hand and not use Ecto. It was extremely enjoyable writing every que

Heh. Recently I had to stand up a quick elixir project and decided to write all queries by hand and not use Ecto. It was extremely enjoyable writing every query from the start. Just thinking carefully about what columns I needed, and crafting the best joins and where clauses made efficiency baked in from the beginning. If one is not careful and just be lazy with an ORM you get back all columns all the time - and this is the biggest sin of an ORM. Not to mention sub-optimal where clauses that kill performance. And the next positive side effect was the amazing speed of the database interactions in the app. It’s not something I’d do all the time since sometimes you do need the discipline of Ecto, but I say we should write more sql by hand instead of less.

c0balt 5y ago
The problem is that writing SQL by hand tends to led to more errors. Experienced devs might be able to minimize those errors (and potential vulnerabilities, remember all those injection bugs?) but especially for junior devs I would recommend using an ORM to avoid shooting themselves in the foot. The question is Performance <=> Security, which is most likely gonna be security for most people on the data/ application layer.
makeitdouble 5y ago
If you’re not careful and just be lazy with your hand crafted queries you’ll miss updating old queries when you alter your schema. You won’t convert your types the same way in each places you query the data, or you’ll forget checking your data’s consistency where it’s falling in the cracks between your SQL rules and the application’s requirements. The “not careful and just be lazy” way won’t get you in a good place whatever approach you take.
- eric4smith 5y ago
  The PG Driver through the Ecto Repo nicely handles and converts all the database types into Elixir types handily. Integers go to Ints and JSON B gots into Maps as one would expect.
dnautics 5y ago
Ecto is pretty damn nice (also technically it's not an ORM - and that's not a trivial distinction). Yeah, it adds a little bit of latency, but that will usually be overshadowed by the DB transactions... Am I mistaken about this? Are you not afraid that your queries will have SQL injections? Or handle unicode poorly, binary blobs, etc? > you get back all columns all the time I think this is why you can map multiple schemas to the same table in Ecto
- eric4smith 5y ago
  Ummm we use the PG driver through the Ecto Repo which handles SQL injections.
ramchip 5y ago
For some data e.g. users I use two Ecto schemas for the same table, one with the full data and one with a small subset (id, username, full name). This makes it really easy to load just the data that's truly needed in associations etc.

c0balt 5y ago

The problem is that writing SQL by hand tends to led to more errors. Experienced devs might be able to minimize those errors (and potential vulnerabilities, remember all those injection bugs?) but especially for junior devs I would recommend using an ORM to avoid shooting themselves in the foot. The question is Performance <=> Security, which is most likely gonna be security for most people on the data/ application layer.

makeitdouble 5y ago

If you’re not careful and just be lazy with your hand crafted queries you’ll miss updating old queries when you alter your schema. You won’t convert your types the same way in each places you query the data, or you’ll forget checking your data’s consistency where it’s falling in the cracks between your SQL rules and the application’s requirements. The “not careful and just be lazy” way won’t get you in a good place whatever approach you take.

eric4smith 5y ago
The PG Driver through the Ecto Repo nicely handles and converts all the database types into Elixir types handily. Integers go to Ints and JSON B gots into Maps as one would expect.

dnautics 5y ago

Ecto is pretty damn nice (also technically it's not an ORM - and that's not a trivial distinction). Yeah, it adds a little bit of latency, but that will usually be overshadowed by the DB transactions... Am I mistaken about this? Are you not afraid that your queries will have SQL injections? Or handle unicode poorly, binary blobs, etc? > you get back all columns all the time I think this is why you can map multiple schemas to the same table in Ecto

eric4smith 5y ago
Ummm we use the PG driver through the Ecto Repo which handles SQL injections.

ramchip 5y ago

For some data e.g. users I use two Ecto schemas for the same table, one with the full data and one with a small subset (id, username, full name). This makes it really easy to load just the data that's truly needed in associations etc.