To ORM or Not to ORM • Hacker News Board

Re: To ORM or Not to ORM

#111

Post by ozim » Tue, May 07, 2019, 7:56 PM UTC

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

Actually "writing queries in some language other than SQL" which has static typing and catching issues in compile time is quite big for me. Add automatic database migrations that are also keeping types in line with code and whole bunch of "mess of mapping code" goes away. Though I use .NET EntityFramework which by now is really mature and heavily invested into by MS. Not sure how it is with other environments but I think I have it too easy.

Re: To ORM or Not to ORM

#112

Post by kyllo » Tue, May 07, 2019, 7:56 PM UTC

out_of_protocol wrote: post #102

For everyone complaining about orm-something - take a look at elixir's Ecto. It basically allows writing sql via native code. Good for composability, type casting, stuff like that. Account |> where(active: true) |> join(:left, [a], p in Post, on: p.account_id == a.id) |> where([a, p], a.foo == "bar" or p.bar == "foo") |> group_by([a, p], a.id) |> select(...) |> limit(10) ... |> Repo.all() Plus there are changesets fo…

This is my preferred approach--a fluent, composable query builder API that uses pipes.

When I do data analysis with R, this is what I use--same concept: https://dbplyr.tidyverse.org/

The somewhat tricky part can be converting the tabular result set into a graph of objects, but I think it's better to handle this in your application code as needed, rather than delegate it to a library.

Re: To ORM or Not to ORM

#113

Post by akmiller » Tue, May 07, 2019, 7:58 PM UTC

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

Or use a language with great data structure support so you don't have to create objects at all!

Re: To ORM or Not to ORM

#114

Post by robodale » Tue, May 07, 2019, 7:59 PM UTC

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

After having written queries to populate whatever platform data structures take the result...to mothership-sized ORMS that keep you as far away from SQL as possible, I have to say a middling ORM like Dapper is optimal for me.

It's lightweight when you want it to be, but if you want to do some heavier/generic use...it can take you quite far.

Re: To ORM or Not to ORM

#115

Post by bunderbunder » Tue, May 07, 2019, 8:00 PM UTC

d4mi3n wrote: post #82

hardwaresofton wrote: post #65

While I learn towards not using an ORM, the productivity gains (at the very least early on in development) are undeniable. What I've always looked for are frameworks that give you an ORM but also make lower level queries very easy, normally via a query builder, allowing you to go back and forth between levels of abstraction. If I had to choose, I prefer libraries that give you the lower level of abstractions first an…

There's another big aspect of ORMs a lot of people tend to skip in discussion: Security. Raw SQL can be dangerous, and given enough people and code somebody will eventually make a mistake (as is human) and introduce a vector for a SQL injection attack or some other DB specific vulnerability. A good ORM can be a fairly effective layer of safety.

It can be, but it is hardly the only solution to that problem. I've also seen it solved, for example, with a git commit hook that just bounced any non-parameterized queries.

Re: To ORM or Not to ORM

#116

Post by gigatexal » Tue, May 07, 2019, 8:00 PM UTC

Go with an ORM when your schema is still in flux but transition to raw SQL when you can the tech debt and performance overhead is just insane otherwise.

Re: To ORM or Not to ORM

#117

Post by Grollicus » Tue, May 07, 2019, 8:05 PM UTC

I'm surprised with so many mentions of Django nobody mentioned the migration system.

I've hand-written sql (the good old days of mysql_real_escape_string) and I've used some ORMs.

Django stands out because of their code first-approach for models: You define models in Python and they generate migrations based on that.

That makes updating very easy and also quite robust, as a simple makemigrations call in the CI ensures your DB is not out of sync.

Re: To ORM or Not to ORM

#118

Post by pageandrew » Tue, May 07, 2019, 8:06 PM UTC

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

I'm looking for a lightweight ORM like Dapper for Golang. Anyone aware of something decent?

Re: To ORM or Not to ORM

#119

Post by talkingtab » Tue, May 07, 2019, 8:11 PM UTC

The number one reason to use SQL is not a reason not to use an ORM. SQL is extremely powerful - it can make your data sit up, roll over, play dead and even speak. Learning how to harness that power is worth while. So maybe use an ORM now, while you are learning SQL.

Re: To ORM or Not to ORM

#120

Post by JamesBarney » Tue, May 07, 2019, 8:12 PM UTC

ozim wrote: post #111

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

Actually "writing queries in some language other than SQL" which has static typing and catching issues in compile time is quite big for me. Add automatic database migrations that are also keeping types in line with code and whole bunch of "mess of mapping code" goes away. Though I use .NET EntityFramework which by now is really mature and heavily invested into by MS. Not sure how it is with other environments but I t…

Not to mention code reuse. Say for instance we have one query that finds eligible bachelors near me and another that finds newly eligible bachelors. We need two queries but they both rely on the same underlying domain concept of "eligible bachelors". In entity framework it's easy to save that as an expression that can be reused in multiple places. It's hard to do that in sql in a maintainable way.

Not to mention refactoring issues. If I decide to change a datetime field called time to split it into a datetime and offset that change is far safer in c# than it is SQL.