Live data from Hacker News

What ORMs have taught me: just learn SQL

wozniak.ca

181–190 of 245 posts

Re: What ORMs have taught me: just learn SQL

#181
post #84

I used to write raw SQL for many years, then, around 2005 switched over to ORMs in order to be able to target different databases, have a nice model, etc. Lets be honest here, the ease of justing doing: p.username = "Carl" p.age = 33 p.save instead of "update users set username=:username, age=:age where id=:id" has a ton of advantages. For one, some sort of syntax or type checker is actually trying to understand your…

YeSQL seems a little bit like it's reinventing the Microsoft data access ecosystem of 10-15 years ago - stored procedures behind a code-generated API. Retro is cool. The Clojure SQL ecosystem is weird. clojureql seemed wonderful for a while, but has been left to rot and the fact that nobody's really picked it up implies people have just moved on with their lives. Korma and YeSQL seem to handle most of the Rails-like…

Except stored procedures have to be stored in the database AND usually end up in source control too. At least with this library there is one source for your queries. Also, they are compiled into your language as first class functions, which I like too... kind of like how JSON is a first class citizen in JavaScript.

I really like the approach.

Re: What ORMs have taught me: just learn SQL

#182

Interestingly enough, no one ever listened to Gavin King (creator of Hibernate), when he said that you shouldn't use an ORM for everything. It is relatively easy to draw a clear line between using: * ORMs for domain model persistence (complex, stateful CRUD) * SQL for relational model interaction (complex, stateless querying) Bottom line: * Don't use ORMs for querying * Don't use SQL for complex CRUD

Thank you for sharing this. Do you have a source for this quote? It completely reflects my experience over the years of what makes sense given the relative merits and pitfalls of each method.

Yes, the source is here:

https://plus.google.com/+GavinKing/posts/LGJU1NorAvY

Re: What ORMs have taught me: just learn SQL

#184
I agree with Woz. Any developers working with RDBMS should learn SQL. ORMs are just wrappers for SQL statements. They are not the same thing, and knowing one without the other means your skills are weak.

Many comments in this thread are painful to read.

Re: What ORMs have taught me: just learn SQL

#185

I'd rather write Django ORM than write create and alter table SQL, and migration SQL any day of the week. The developers who wrote Django's ORM are also way better at writing SQL and database related code than I am and sure I could spend all the time I need to become so proficient that my migrations work as nicely as migrations and syncing in Django and Django related projects like south, or I could just spend that t…

To be sincere, I find Django's ORM is one of the weakest ones (e.g., the API doesn't support a simple GROUP BY). If you want to make a good case for ORMs, Django's may not be a very strong argument. In about 5 years working with Django the ORM has been the only component that consistently gave headaches. I have filled a couple bug reports about it generating non-sense/slow queries too (like generating queries with `D…

>the API doesn't support a simple GROUP BY

This is just plain wrong (see aggregate/annotate).

Re: What ORMs have taught me: just learn SQL

#186
post #154

Earlier quoted context omitted.

Writing sql by hand doesn't have to mean you abandon things like autocomplete and automatic highlighting of typo's. SQL can be inspected by a proper ide just like any other language.

To be fair, SQL has a syntax that is hard to provide (for example) autocompletion for, as the table comes after the fields, and the field names can be ambiguous.

Postgresql command line (psql) still manage to do an excellent job at it (but I concede it's pretty hard to replicate)

Re: What ORMs have taught me: just learn SQL

#187

Another problem with ORMs is that they make performance diagnostics much harder. DB-side, you might have a list of worst-performing queries and examining it reveals a huge, hundred-line monstrosity of a query. Because the queries are ORM-generated and are not usually very readable it isn't exactly clear which part of the application is generating it (or why). Even further, if your DBA says you could make the query mo…

Django makes queries that are quite readable (and optimized! It makes good decisions to reduce the number of queries), and you can see exactly what SQL is run with the Django Debug Toolbar.

So "[ORMs] make performance diagnostics much harder" is just not true. "Some ORMs make performance diagnostics much harder" definitely is.

Re: What ORMs have taught me: just learn SQL

#188
post #121

Earlier quoted context omitted.

The same in Scala + Slick would be: val q = Users.filter(_.userType == UserTypes.Basic).map(_.group) Although I'm not sure what the context.Users.Include bit in the EF example is doing. Both will generate statement at compile time, and I assume EF queries are composable as is the case with Slick. Slick's readability does suffer though with more complex queries -- unfortunate they strayed away from SQL semantics in fa…

Include() on an ObjectContext will return the corresponding foreign key objects. It's a poor man's join to related entities. There is also Join(), but that will join by anything.

Ah ok, I see. Slick actually does have a nice shorthand for fkey joins:

    val q = for{
      ur 
which would produce semantic equivalent to:

    select ur.id, ur.a, ..., u.id, u.a ...
    from userrole ur
    join user u on u.id = ur.userId
    join role r on r. id = ur.roleId
grouping and sorting is where Slick becomes less readable SQL-like DSL and more boilerplate DSL full of meaningless tuples O_o

Re: What ORMs have taught me: just learn SQL

#190
People should try out InterMine. It's an ORM (and other tools) that I wrote a while back, and runs the backbone of a few genetics research databases. Funnily enough, the object-oriented query language shared almost all its syntax with SQL. It also does a load of things to avoid some of the problems in this article.

If it ain't broke, don't fix it.

Post reply on HN