Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What ORMs have taught me: just learn SQL

wozniak.ca

Post reply on HN
Print view View original

111–120 of 245 posts

Re: What ORMs have taught me: just learn SQL

#111

Post by Daishiman »

marcosdumay wrote: post #99

"I much prefer to keep the data definition in the database and read it into the application. It doesn't solve the problem, but it makes it more manageable. I've found that reflection techniques to get the data definition are not worth it and I succumb to managing the redundancy of data definitons in two places." My experiency is almost the oposite of that. I've found that automatic migrations are one of the best feat…

A thousand times this. Especially since somewhat common operations for DDLs are vendor-specific, such as adding certain types of indexes, and ORMs just abstract that away very nicely.

Re: What ORMs have taught me: just learn SQL

#112

Post by johan_larson »

The worst part about ORM is that there are so many systems for doing it. Out of six employers, two had their own handrolled ORM systems.

I think what's going on here is that elementary mapping of objects to and from relational tables is really easy and obvious, so people go ahead and implement it. Unfortunately once you get past the easy bits and have to worry about breaking objects across tables, foreign keys, transactions, caching, and other fun stuff, you have a great big mess and you probably messed up some of the edge cases.

Re: What ORMs have taught me: just learn SQL

#113

Post by taspeotis »

snarfy wrote: post #87
makmanalp wrote: post #33

Over and over I keep finding that just an ORM is not enough, but raw SQL is hideous in a different way. ORMs map nicely when you are indeed modifying objects, but somethings don't map well that way. So don't map them that way! What we need is a low level abstraction layer alongside the ORM. The main problem with raw SQL is that what you really want is a genuine programming language. You almost want programmatic acces…

>The main problem with raw SQL is that what you really want is a genuine programming language. You almost want programmatic access to the SQL AST, so you can generate syntax as opposed to concatenate strings together. Kind of like a DOM API, but for SQL. What you described is basically EF+LINQ. var query = context.Users.Include("Users.Group").Where( u => u.UserType == UserTypes.Basic).Select( u => u.Group); That's go…

> You can even do ToTraceString() to see the generated statement.

And then if you're a control freak, feed that generated query into ScriptDom [1].

[1] http://msdn.microsoft.com/en-us/library/microsoft.data.schem...

Re: What ORMs have taught me: just learn SQL

#114

Post by NDizzle »

elithrar wrote: post #93
learc83 wrote: post #71

Earlier quoted context omitted.

Is there something like YeSQL for Go?

Not that I've seen, but I've love to see it. You could probably build it with something like text/template and write: SELECT id, title, expiry_date FROM posts WHERE id = {{ id }} AND expiry_date > {{ date }} ORDER BY expiry_date This would give you some flexibility--the template tags would be replaced by ? or $1 or :name depending on the database driver set on parse--and leans on the stdlib. This would tie in nicely…

Forgive my ignorance as I'm not very familiar with golang, but what you're describing above looks (to me) like a parameterized query. Nothing real fancy about that. I'd assume that Go has support for parameterized queries already.

Re: What ORMs have taught me: just learn SQL

#115

Post by segmondy »

I always let the database do heavy lifting. I write 100 line SQL that if you turned into code, will turn into 1000 line of code. It scares most folks but whatever, it runs much faster and once it has been fined tuned, runs fine without needing much. I just comment the hell out of it.

Re: What ORMs have taught me: just learn SQL

#116

Post by GrinningFool »

aikah wrote: post #100
meritt wrote: post #49

ORMs are great for simple CRUD operations. As soon as you want to do anything mildly complex or desire efficiency, you need to write SQL. As long as the ORM helps me with the former and gets out of my way for the latter, I'm totally happy to utilize then.

that's absolutely not true.Sure you cant write a procedure with an ORM. But good ORM have query builders that with allow you not to write ANY sql.At all.ORMs are not just about CRUD at all.

The biggest downside to this that I found is that you have to have a lot of trust in the creators of that ORM.

SUre, it will generate a query that gets you what you want - but will it use the right indices? Will use correct ordering for optimal results?

Generally (unless this has changed in more recent years) the answer is 'no'.

Re: What ORMs have taught me: just learn SQL

#117

Post by [deleted] »

kyllo wrote: post #86
jdotjdot wrote: post #76

Earlier quoted context omitted.

If you're at all interested in opening a kick starter for such a templating library for Django, I'd back it. I have attribute creep all the time and actually generally prefer raw SQL with the exception of its verbosity. The problem is, migrations are awful and SQL injection mistakes easy to come by. Would be great to have the best of both worlds in a SQL templating engine + sort-of ORM wrapper that auto-generates via…

Without the ORM, though, what would be the point of using Django? To me it seems like this would be a better fit for a more minimalist platform like Flask.

[deleted]

Re: What ORMs have taught me: just learn SQL

#118

Post by lexx »

If I have to code a serious application with complex schema, ORM is out of the discussion. If I want to kick fast prototype project I would consider it. But in the end I know that I will regret it!!!!

Great article!

Re: What ORMs have taught me: just learn SQL

#119

Post by cmelbye »

learc83 wrote: post #71
terhechte wrote: post #27

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…

Is there something like YeSQL for Go?

  getUser, _ := db.Prepare("select * from users where username=$1 limit 1")
  row := getUser.QueryRow("john")

Re: What ORMs have taught me: just learn SQL

#120

Post by virtualwhys »

snarfy wrote: post #87
makmanalp wrote: post #33

Over and over I keep finding that just an ORM is not enough, but raw SQL is hideous in a different way. ORMs map nicely when you are indeed modifying objects, but somethings don't map well that way. So don't map them that way! What we need is a low level abstraction layer alongside the ORM. The main problem with raw SQL is that what you really want is a genuine programming language. You almost want programmatic acces…

>The main problem with raw SQL is that what you really want is a genuine programming language. You almost want programmatic access to the SQL AST, so you can generate syntax as opposed to concatenate strings together. Kind of like a DOM API, but for SQL. What you described is basically EF+LINQ. var query = context.Users.Include("Users.Group").Where( u => u.UserType == UserTypes.Basic).Select( u => u.Group); That's go…

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 favor of Scala collections. We'll see where it goes...

Post reply on HN