Hacker News Reader

Comment by mapgrep | Hacker News Reader

Ya I’ve heard this one a lot. It’s kind of funny to say and does humorously underline the complexity of the problem but people take it seriously. So to take it seriously for a second:

There was no good reason to be in Vietnam; even taking the stated rationale as a given, which many people did not, it was a concern many levels removed from the actual safety or functioning of American society.

ORMs in contrast achieve much more proximate goals — they solve a real problem and can measurably reduce the amount of code you have to write. It is tedious to write the same sort of SQL query over and over. Even if you prefer to use literal sql for the complex stuff (as I do), ORMs tend to be a significant win (in fewer LOC to write) on abstracting out basic queries.

View on HN

Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect.

The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches.

There are two reasons to use the ORM: to not learn SQL, and to generate SQL.

The first reason is the commonly provides one, and what leads us into vietnam. The latter is why people try to avoid ORMs, yet find themselves back in vietnam.

What we really need is a less shitty version of SQL.

Something like jOOQ?

https://www.jooq.org

Ye. Static typechecking is the only thing in his list that I really care about, since you can "git gud" at SQL and not be bothered by the syntax/ordering/parser concerns. jOOQ is exactly what I want to bridge the gap between Java and the DB.

The ordering is always a problem, because your logic may not follow it. Eg if your set of conditions apply to multiple queries, then you might know your where conditions before you know your select/from clauses.

So instead of building up your sql string in a straightforward fashion, you need to have at minimum an abstraction that delays construction.

You get lead into vietnam as almost a direct result of SQL’s context-sensitive clauses.

Or you could go with LINQ's approach from (x) where (y) select (z).

Honestly, I think LINQ and entity framework successfully solved most ORM concerns

That looks fantastic. No magic mumbo jumbo mapping, just a simple type safe sql. Both syntax safety (no need to remember which of WHERE and HAVING comes first) and type safety on all fields. It's not advertised in the examples on the front page but i also take for granted sql injections are completely impossible since all data goes into functions and are not string formatted, without the mess of having to remember the order of arguments as with prepared statements.

Anyone got tips on similar frameworks for other languages than java and for other dbs.

Dapper for C# made by StackOverflow team

https://github.com/StackExchange/Dapper

An ORMish thing that considers its primary purpose to enable metaprogramming SQL is actually useful.

In http://p3rl.org/DBIx::Class perl has had such a thing for over a decade now.

It makes me cry that nobody's ever adequately cloned it into other languages. Eventually I'll probably do so myself.

Isn’t that just a query builder? I’m not familiar with Perl or your library, so maybe you could tell me where I’m wrong?

What I was trying (and evidently failing) to say is that a sufficiently powerful query generation system that's designed for people who actually like their database to be able to generate the exact SQL they would've written by hand is essential to the 'mapper' part of the equation being able to smooth out any impedence mismatches between the appropriate object model and the appropriate database schema.

Hopefully that longer answer is a bit clearer than my first attempt.

I guess I don't know enough Perl to understand how this differs dramatically from something like SQLAlchemy in Python.

SQLAlchemy is pretty close. Been quite a few years since I've had a chance to get drunk with the authors and compare notes though, so I'm not going to try and get into details because I'm pretty much guaranteed to get some of them wrong.

> What we really need is a less shitty version of SQL.

I think the same. In my spared time I building a relational language (http://tablam.org ..accept more help!) starting even lower: Without a rdbms.

I work in the past with FoxPro, and was possible to build a full app with UI and reports and all stuff you can imagine with a database-oriented language. You code the UI on fox, query with fox, make triggers with fox, etc...

I'm looking in capture the same essence.

I have found the best ORMs don’t hide their SQLness much. SQLAlchemy is pretty great, but you don’t get full use out of it unless you have your arms around SQL itself. When you use an ORM to cut down on chores it’s great. When you use an ORM to avoid your datastore and it’s idiosyncrasies it is worth taking a long hard look at why :)

Most of the ORM interactions are well formatted code that don’t hide the datastore much. As long as you let the ORM map in objects and it’s performant, life is alright. When the ORM starts running the show there may be no coming back.

I enjoyed this comment because I only I only recently tried Sqla for a project and agree fully that it embraces sql, in large part by NOT renaming/rethinking things at the oop level - methods very much tend to be named after sql verbs. I really liked this.

What I liked less was all the setup/config ceremony. Compared to ActiveRecord (the Ruby lib not necessarily the orm concept) I was using more LOC before I got to the part where I started saving time on simple queries. I realize this is because sqla uses the datamapper model. But for me thif sweet spot would be auto setup like AR with sql-like syntax of sqla.

Yeah. When you get good at composing SQLa code it is really nice. You can functionally build your queries and DB interactions. It just fit well with my way of coding. ActiveRecord had a lot of magic to my taste, but you could still drop down with it. Agree SQLa can be tedious at first. No tool is perfect :)

> What we really need is a less shitty version of SQL.

Any of the D (Date and Darwen's, not Digital Mars’s) family of relational languages might fit the bill.

    > What we really need is a less shitty version of SQL.

My view is the opposite. The power of SQL perpetuates a low-quality software culture. The root issue is a dev culture that can't see past databases.

A lot of software design runs like this: (1) translate business patterns into a relational schema; (2) build interactions with that schema; and (3) as that gets harder, use SQL arcana and ORMs and views and stored procedures to squeeze out flexibility.

I worked like this for the first decade of my career. My systems got some use, and struggled along, but they are failed projects.

Repeatedly I had this feeling: the project is almost done, but there are some concurrency issues where I would not even know how to start addressing them.

The database-centric design made it impossible to work past that.

After much searching, I came to this: Stored State is a brittle and unwieldy thing, and you want as little of it in your life as possible. The more you have, the harder you have to work to get anything done. Databases are an institution of Stored State.

As an alternative, you can derive state from messages.

> As an alternative, you can derive state from messages.

Bingo!

Unfortunately, if people won't even listen to Alan Kay on this stuff, who will they listen to?

What is the solution then? Are you talking about event sourcing or something different?

I see the same problems but it usually caused by a reluctance to modify the database schema. Once you get comfortable doing that and keep your schema matching the requirements then it solves a lot of the problems.

What kind of concurrency issues were you running into with a RDBMS that has atomic transactions?

Are we talking about distributed store situations where CAP theorem limits apply, or something else?

> ORMs in contrast achieve much more proximate goals — they solve a real problem and can measurably reduce the amount of code you have to write.

Why would you optimize for LOC rather than expressing the behavior you want well? In some situations sure—rapid prototyping—but that’s an odd assumption in a general case.

If you haven't read that post, it's worth reading in its entirety. The title is not the entire argument.

Reply on news.ycombinator.com