Hacker News Reader

I don't feel any of those limitations using SQLAlchemy. Most projects just end up implementing a subset of ORM features poorly. I think your experience as an ORM author and contributor may rather uniquely qualify you to write "a bit of DRY glue code".

Good ORM lets you use a small slice of their features without any big performance hit in terms of development or actual. With a nice object model it just seems easier to remember and work with code.

When I need complex SQL I just write a raw query... It is trivial and concise in any ORM to drop down to raw SQL when needed.

I can agree they are no silver bullet, but a good ORM does so many chores for me I can't imagine bothering to do them myself, anymore when the pattern of using objects in my code and storing them in a SQL DB solves the problem at hand.

> I think there's a case to be made for less abstraction in programming in general, and access to data stores is a major part of that.

I'd like to hear more of your thoughts on that.

My experiences with ORMs are less about too much abstraction, and more about them encouraging wrong abstractions. I'm yet to work with an ORM-using project that doesn't employ ORM objects as business model objects. The ones I've worked with always exploded due to the fact that even with ORM, database model doesn't map 1:1 to how the business logic would like to see the world - and the tension of trying to use one set of objects for both purposes at the same time is what messed up the codebase.

> I'd like to hear more of your thoughts on that.

These days it seems that even for the most rudimentary programming tasks everybody reaches straightaway for their favorite framework/lib without too much thinking.

I think in a way all these frameworks and libraries have had a negative impact on the general quality of coding. Programmers end up with limited knowledge of how the underlying technologies work: the HTTP protocol, SQL, the DOM...

And because these frameworks tend to grow over time, in an effort to be comprehensive and serve everyone's needs, they introduce more and more dependencies, more and more tooling, more and more code, which you'll need to get to know sooner or later.

Programmers who use said frameworks and libs become more and more "hooked", start using more features than actually needed (do you really need that auto generated REST API for that 3-page dry cleaning website?), and in the process become, well, dumber.

You can of course take this argument to absurdity by claiming that everybody should just write machine code. That's of course not what I mean. I just think that for many programming tasks, programmers would be better off - and no less productive - just by attacking the problem head on, with a good understanding of the technologies involved.

Sometimes a simple handsaw is more efficient and less hassle to use than that fancy sophisticated table saw you got in the corner.

Sequel was the last one that I used and was the best one. I can't remember the talk..."ORM's are the Vietnam of programming".

You are right, very little of the ORM gets used in the end and one almost always needs to write custom SQL anyway (models don't always map 100% to app layer). Most importanly, as languages change, evolve or dry up it's easier to find or train new talent with SQL experience vs. a language specific ORM.

>I can't remember the talk..."ORM's are the Vietnam of programming".

Had seen that article a while ago. Saw a few other mentions of it already in this thread, but here are a few I googled for and found:

http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... (the original, maybe)

HN thread:

Object-Relational Mapping is the Vietnam of Computer Science (2006) (codinghorror.com) https://news.ycombinator.com/item?id=7310077

https://blog.jooq.org/2012/05/09/martin-fowler-on-the-vietna...

I haven't been a big fan of ORM's even before DataMapper in Ruby. I found that it was too easy to make non-performant queries and found myself writing raw SQL anyway.

Some argue that using an ORM means you can switch underlying database technologies on a whim. I think this is an incredibly weak argument. How often do people truly switch database technologies?

I created a small wrapper around the node postgres library to make querying a little easier.

Have a look at https://github.com/joeandaverde/tinypg - It's a no frills library that makes it easy to execute SQL files as prepared statements and pass parameters as keys on objects.

I've been battling a lot of cases where I don't want to duplicate SQL statements in my application. For example I have a query defined which I want to add a WHERE clause to. How do you handle these cases elegantly in code?

Some databases treat the query themselves as components that can be chained together before execution, look at RethinkDB and ReQL. For SQL, there are lots of ways to make dynamic sql (generated by code) and while the patterns are many the implementation in the language often looks bad and breaks most sql injection protections when using db middle ware.

Would love to see the DRY glue code.

A lightweight PostgreSQL-based Ruby object store using JSONB, in ~ 100 LOC:

https://gist.github.com/ciconia/57ad430cf437f0548d596a6f0026...