Hacker News Reader

Comment by 1gor | Hacker News Reader

   be careful with ActiveRecord

What alternative ORM would you recommend that is mature enough?

View on HN

I've heard good things about sequel, but have never used it personally: http://sequel.rubyforge.org/

I use Sequel when I am doing projects in Sinatra. It's elegant.

The sequel approach is unique. I worked with it a year or so ago and was happy.

Datamapper (http://www.datamapper.org) is a great alternative as well.

It's not as full-featured as ActiveRecord, but then it's also not nearly as heavy!

"I'll come out of the closet about this and just say what everyone knows: If the DataMapper community had more of a focus on addressing known, ticketed, reproducible bugs and less on pouring thousands of man-hours into writing specs it would be usable today. Frankly, I would recommend against considering it for your next project in the strongest terms possible.

Considering I created the project, nursed it through it's first couple years of development, and invented patterns like Strategic Eager Loading and Lazy Loading Contexts, which no other O/RM has to this day to my knowledge, that should say something. It's an epic fail of a project at this point."

-- Sam Smoot

http://robots.thoughtbot.com/post/162764036/why-do-rubyists-...

wow, that's a tough quote from Smoot. I use datamapper for an app in production and have no problems, but to be fair, my RDB access is very straightforward and I don't use any of the relations DSL stuff.

Although I think a lot of Sam's work, his boast of inventing patterns of "Strategic Eager Loading and Lazy Loading Contexts" is hard to take. I wrote stuff like this in Samlltalk in the early 90s and again in Java in the late 90s.

From my perspective, I don't trust any of the ruby ORMs. I constantly watch the SQL they generate thinking any day I'll catch an error. This isn't to berate the developers, but to acknowledge that the approach to solving this problem domain is too "magical" for my tastes. This is one reason with my new app I'm going with mongodb. I get a less trusted DB, but my ruby code accessing it is closer to the metal.

On the "boast", that probably came off a bit strongly. I'm pretty much a dick online. And in person my friends tell me... :-D

Anyways, yes, OK, nothing new under the sun. I don't doubt better programmers than me did this awhile back. I'm just not aware of another OSS or Commercial O/RM that provides it, and I'd never seen it before.

Also, I can't take credit for actually _implementing_ the Lazy Loading Contexts... that was someone else. Really smart guy, but he dropped out of the project eventually.

DM is just crazy sometimes, but with 0.10 Dan says that's changing. I'd trust it again when someone big deploys and raves about it, I just don't have any motivation to investigate it personally. I think there's better things to spend your time on considering Sequel is around. Why fight it?

I took code from Sharon early on (connection pooling), he took code from me (block query syntax), Sequel is kinda the best of both worlds. I've never thought building an O/RM on top of a Table Data Gateway was a good idea, but that's mostly a performance concern, and Sequel's performance is right up there so does it really matter?

My only concern with Sequel is that last I looked it's not as robust as Hibernate when it comes to aliasing tables. But then what is? It's probably a rare enough issue that you can just get around it with the sproc or ad-hoc query support once or twice in a given large app.

Hi Sam!! Hope you didn't find my post critical of you. It wasn't my intent. I'm very grateful for the high quality work that is/was datamapper and for your support while I was learning it.

All good programmers boast about a thing or two they "invented", me included. I wouldn't have it any other way. ;)

Jon, no offense at all.

I just looked at your site and realized you were the guy I've been feeling sorry for all this time since you were one of the early production adopters. I'm glad to hear it's been a pretty smooth experience. I can stop carrying around that guilt. ;-)

Oh, and since this thread is about Web Frameworks, try Harbor (http://wiecklabs.com). :-D

Lesson learned about being to vocal/open too early, but Harbor and the related projects are seriously good stuff if I do say so myself. Also look for a major open-sourcing of a user-management/authorization system built on Harbor in the next day or two at http://github.com/wiecklabs.

Harbor look cool. I'll keep an eye on it!!

There are responses from dkubb and wycats, and the conversation shows it's not that simple and that there are other perspectives, as is often the case.

Wycats is in marketing. His biggest contribution was inventing the term "Strategic Eager Loading". He made no significant code contribution.

True, he did generate a SWIG wrapper to create the first prototype of DataObjects after a conversation we had where I suggested Ruby would be a better place with an ADO.NET-like database interface... but none of that was really usable since you had to have the exact same MySQL version down to revision, on the same system. The only other major contributor to DataObjects outside of the Wieck team I recall (and apologies if I missed anyone) was Dirjan Bussink fixing my broken Connection Pool. Later contributors (and Dirjan) ended up rewriting a lot of it for Asynchronous Execution, more driver support, etc. But that's the reason the thing looks so much like ADO.NET.

Oh, and Command#set_types was me too. Which is the reason DO is the fastest (last I bothered to look) database API for Ruby.

The marketing contribution was HUGE. It always surprised me how many new people showed up after one of Yehuda's presentations. DM wouldn't be what it is today without Yehuda. But your own opinion on DM's code is about as valid as Yehuda's. Just look at the commit-history.

I love that Datamapper will build a working database from nothing just given the class definitions; no migrations, no schema definitions, just a URL to the database instance. Database access with Datamapper is completely frictionless, unlike with AR.

It really depends on your needs. My comment was in regards to the memory footprint. There was an Engineyard blog post about that recently. Basically if you do some non-obvious things, you can just explode out the size of ram, and because of how ruby works, it'll never get given back to the OS.

Edit: http://www.engineyard.com/blog/2009/thats-not-a-memory-leak-...

Poor use of an ORM (or pretty much any robust full-featured library) has its risks. I'm not sure how you provide features that AR includes without putting your memory at risk of overuse.

Model.find(:all) is going to be problematic across the board, there will always be a risk when you start playing with things like including children (there's a great benefit as well). You need to know what you're doing with any ORM.

Reply on news.ycombinator.com