Hacker News Reader

The main practical benefit of object wrapping (ActiveRecord in particular) is that it gives you a more structured way to lay out the model-related logic for your app. Callbacks, model validations, and associations in particular allow you to easily compartmentalize a lot of the details of your models. If you're looking for ways to reduce the complexity of the problem space in your head, ActiveRecord et al are great ways to do it.

(ymmv. If you eat, sleep, think, dream, and make love in SQL, I guess you might as well ditch the ORM)

There's a lots of answers to your question, John. I'll try giving you a couple.

One -- I might want my data to live in multiple places. For instance, I had an app I wrote recently that could persist its data to and from three places -- SQL, a funky XML format, and a private file format. That's too much read/write crap to pollute my app with.

Two -- I might want my data to live in multiple versions. If you've got multiple versions of your data format out there, such as if you were Quicken or something, you want to change/modify the data code in one spot, not all over the place.

Three -- the job of writing the UI is different than the job of knowing about data. Whether it's one box or ten thousand, one table or five, why should I care/know where the data lives? I'm writing the UI for goodness sakes. Just make the stupid stuff go away and come back when I need it. One well-constructed data tier should be able to service a hundred UI developers.

When coding imperatively and using a "short-cut" data access paradigm like RoR or CodeSmith and NetTiers (my favorite), the temptation is to start thinking well gee, if every table is an object, what's the point? Why not just hit the database directly? The answer is that you're coding just using a big shortcut -- it ain't going to work all the time like that. You have to know why the shortcut works and why it doesn't work.

I would take a serious look at Django. You can use it as scaffolding and get rid of pieces as you write you own, the first to go will be the use of the automated admin site, and I find myself writing a custom pieces across the board.

However, being able to rapidly deploy a prototype has been priceless time and time again, and they have the basics that you need down and well tested.

If you don't like ORM, or find yourself writing a lot of custom queries for performance, that is fine. I would still use an ORM now and customize some queries for performance later. The reason? Speed of building your app...I think not writing the DB code saves me about 20% of my time.

I used to be always against using frameworks since they were massive, crappy, and relied on so much magic you didn't know what was going on behind the scenes. I am really glad I went with Django, it saved me from writing almost the identical feature set.

It's interesting that you mention Django. Of all the frameworks it's the one I most liked as I was investigating for one major reason: the community around Django seemed welcoming and open to ideas. This was very much in contrast to the RoR community which seemed to have a "we know better than you" attitude.

John.

The community is quite good overall.

It is especially good about allowing random people to contribute pieces of code that are useful. I also like how their goal is to make everything as straightforward as possible, and eliminate the 'magic' that most frameworks have. If you have any questions about it, feel free to ask.

Do you feel like you know what's going on behind the scenes in Django? That's my biggest concern with it. (haven't tried it yet.)

I think you'll find that the stuff Django does behind the scenes is quite clear, with very few exceptions. The basic parsing of HTTP requests is dead simple, and although the code for the ORM is hairy in places, what really matters is the SQL it generates, which is pretty clean. And like somebody else said, there's nothing that says you have to use the Django ORM.

One of the nice things about Django is that it's just Python. You can always look at the import statements in a module to see exactly what code is being run and where it's coming from. I've never used Ruby on Rails, but I have the impression it can be opaque in this area. ("Just create a file named makeasite.rb and put the single word 'create' in it, and Rails will do the rest!")

Personally, I'm vehemently against "magic" in a framework / programming environment, which is one of the reasons I love Python -- and one of the reasons we don't have a lot of magic in Django.

Let me know if you have any specific questions.

Adrian (Django cocreator / core developer)

No reason to knock the 'magicality' of rails. It works for some people; And since it is only code at the end of the day, you can always get to the bottom of the magic if you do a little digging.

While we are on the topic, I have always wondered why the Django team insists on being an MTV (Model Template View) framework..don't you guys think just conforming to MVC would make life easier for people new to Django? (This is a serious question)

> No reason to knock the 'magicality' of rails.

The problem with relying on magic is that you won't know what to do when it stops working.

The Rails magic is well defined though, and it's all documented. It doesn't simply 'stop working'. It's really nothing more than a set of conventions that happen to make certain things really convenient.

Pretty cool. Ok, it's now on my list of frameworks to try :-)

I avoid ORM completely and am perfectly happy with SQL.

For me, the main benefit of ORM is that it makes it easy to plug in caching (memcache) for just about everything, which you're probably going to want when your reach scale.

I felt in several projects that it wouldn't have been possible to do it without an OR mapper.

Maybe if it's always just select "star" instead of select object, the difference is not so great, but if you can't use select * for some reason, it becomes unbearable for me...

Also, the automatic loading of linked objects and collections, and the caching, are nice features imo. You only have to write object.getMappedThingies() instead of another SQL request (talking about Java here).

SQL is extremely verbose. During my previous life as a Java programmer I moved a project from raw SQL to the hibernate ORM, and removed 10,000 lines of code in the process. Using straight SQL, the data access code was more than 50% of the entire code base. Switching to an ORM got it below 10%.

It really depends on what you're doing, but I can't imagine why anyone would want to write SQL by hand. If you really want simplicity, don't use a database at all.

Are you sure that's SQL and not JDBC?

I moved from PHP/PearDB to Java/Hibernate3.0 to Python/DBAPI, and found that Java was by far the most verbose. Even with Hibernate annotations, I was writing more than twice as much code for equivalent functionality.

Perhaps the difference is that you have business objects defined already, and so the cost of Hibernate is only the annotations? My PHP and Python programs keep the SQL and drop the objects, and so they end up with incredibly tiny data access layers.

SQL is optimized for writing data access queries extremely concisely, so I don't see how it could end up as more than 50% of the codebase, unless you're using an exceptionally verbose database library (JDBC certainly counts) or your codebase is exceptionally tiny.

This app had something like 200 different tables, with 20 to 50 columns in most tables. Update and insert statements were 5 - 10 lines long, and there were hundreds of the things. There was some JDBC cruft too, but the vast majority was SQL.

This was an extreme case of course, and was mostly the result of bad design, but I haven't come across a database backed application that couldn't be trimmed down with some sort of SQL generator. SQL is fine for simple queries, but, for me at least, has always gotten unmanageable in the long term. Need to select, insert and update the same columns? Duplication. Conditionally group by or order by different fields? Duplication. Decide after the fact that you need to support multiple databases, or eager and lazy loading? There goes the weekend, and probably most of next week.

You could manage all of the above with some sort of home grown solution, but a good ORM just makes everything so painless. I was strongly anti-database for years, yet I now often find myself using ActiveRecord when a flat file would do, simply because ActiveRecord is easier.

Of course, that's just me. SQL and I were never a good fit, and I'm glad to be mostly rid of it, but I'm sure others have had different experiences.

Streamlining SQL code generation and mapping tables to objects are two entirely different feature sets in my opinion. 90 % of the reduction in code you're talking about stems from the former whereas 90 % of the complexity of ORMs stems from the latter. That's why I prefer a leaner toolset to interface with the database.

I use a very thin database access library over DBAPI (modeled after PEAR DB, basically just wrapping queries with logging and timing, and converting results to Python dicts instead of DBAPI cursors). It was no problem using this with Pylons, instead of the default SQLAlchemy. If you don't like a Pylons module, just swap it out; the framework is built so you can easily substitute your own components in instead of the defaults.

I used the same library with web.py. Web.py's built-in database library is pretty impractical. Global DB connection means it's very difficult to do testing/mockobjects, and it wouldn't scale beyond one machine.