Dropping Django follow-up: Fundamental ORM flaw | Hacker News Reader

Dropping Django follow-up: Fundamental ORM flaw

blog.brandonbloom.name

23 pointssnprbob8619 comments

I built a Django site with hundreds of thousands of users... Pownce. At Pownce, we started with the basic ORM and dropped down to pure SQL queries for certain often-used or slow queries.

Meh. Problem solved.

How complex was the Pownce schema? (number of tables, columns in the most complex table, number of relationships, frequency of custom data types, etc.) How complex were the usage patterns?

I ask because I'm not interested in performance. I'm primarily interested in having effective domain objects for maintainable use from Python and a clean schema for friction-free use from my database shell. Declarative ORMs seem to straddle that gap to the determent of either end-point.

Most of the time, all you need for optimizing an ORM is a declarative "batch retrieve" framework, where getting one object can also cause the en-masse retrieval of collections of other objects. (Reducing the number of SQL queries by 100X in my experience.) I've written one in Smalltalk that lets you declare the sub-graph of the object model to be batch retrieved as just a list of accessor methods. Before that, I pair programmed with another Smalltalk ORM author while he was fixing another framework. And at my previous job, guess what they had -- another Smalltalk declarative batch retrieve framework! (The last one was written for TopLink)

Right. You'll notice that my article doesn't mention performance at all. I never claimed that ORMs are slow, or that any slowness caused by the abstraction couldn't be easily overcome.

More and more I am realizing that ORMs will always be either flawed or a pain, because relational database technology has not kept pace with modern app programming. The solution is to do away with SQL databases in favor of object db, document db, key-value store, or whatever NoSQL solution most fits the problem domain.

I'm just curious, can anyone suggest a good open source object DB which is also ACID?

Mnesia looks nice, but only for erlang...

We have KiokuDB for Perl. It can store any Perl object graph (including closures; the code and the closed-over state), and it has full transactional semantics.

(And in fact, the transactional semantics are all on by default. If you load an object graph, do some stuff, and save the object graph in a transaction, it will abort if something else modified the data you read at the beginning of the transaction. This prevents you from silently overwriting new data with old data, which is something I did a lot before I knew how to turn this feature on.)

I have used KiokuDB extensively for the typical "web app" things, and it has worked wonderfully. Testing is simpler than with a "real database", and the application goes together much more cleanly. (No O<->R impedance mismatch, since everything is O.)

This sounds familiar:

http://news.ycombinator.com/item?id=866378

Dear mods: This is an experiment. I posted this exact same article yesterday, but with a very plain title. I'm curious to measure the difference in traffic. Please don't kill it? Purdy please? :-) Thanks!

How is that an experiment?

Unless you have controlled groups, the experiment is useless. You have no idea how many people are going to see your domain and the title and figure it's a repost and never click through because of that.

I never said it was a carefully designed experiment.

This post has been up for an hour and already my site has surpassed the number of hits it received in the previous 24 hours. That implies to me that the title makes a significant impact. You don't need to have a control group to learn something interesting with a reasonable degree of confidence.

The conclusion is that the HN population has become prone to sensationalism?

I think your implicit assumption that the HN population previously wasn't prone to sensationalism is unfounded. Press the correct psychological buttons and almost every human will respond.

Personally, I think the HN population is probably more aware of the reason why they chose to follow a particular link, but they still follow it. In this case, the button is curiosity?

Sorry: "become more prone to sensationalism" -- fixed!

My mother always said: Always judge a book by it's cover.

I would have thought that if the aim was to share your thoughts with as many people as possible and generate traffic then you would have used a catchy title by default. That is definitely a major rule in any type of marketing:

You only get one chance to make a first impression.

My aim in writing blog posts is primarily to crystalize my own thought processes. Writing things down is really useful to me. I submit them here to hopefully receive some feedback and spark interesting discussion as a bonus. I'm not pushing an agenda.

I only reposted because of the amazing gap between the number of people who expressed interest in this follow up post and number of people who actually came to view it.

I didn't mean to imply that you were being 'commercial' or only submitting content to gain popularity. I found both the pieces informative, so I'm hardly going to complain!

I was just trying to express my surprise that you were not expecting such a large difference in traffic between the two posts.

If I have a book in each hand and one is titled 'Australia' and the other is titled 'Australia: Mayhem and Sabotage' I know which one I'm going to choose...

I actually wouldn't say this is very controversial, ORM is a problem that (in some ways) is fundamentally intractable. There is some great reading on this subject with an article titled "The Vietnam of Computer Science" (http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...). This was pretty eye opening for me and I think it's a must read for any web developer (or anyone using ORM for that matter).

Thanks for posting this. I came to the ORM party a little late, and am still pretty infatuated with them overall. I was thinking when I saw the link that I've never had a problem with an ORM, but then realized two things:

1) I've only ever used them with fresh projects, where I had control over everything 2) I designed my objects with the ORM in mind.

I'd only ever bumped up against annoyance with an ORM when I was trying to do something with inheretance, and after a brief check into Rails' 'polymorphic relationships,' the requirement was basically dropped anyway.

Hm.

Reply on news.ycombinator.com