Dropping Django follow-up: Fundamental ORM flaw

http://blog.brandonbloom.name/2009/10/orms-and-declarative-schemas.html?foo

by snprbob86 • 17 years ago

23 19 17 years ago

blog.brandonbloom.name

snprbob865• 17 years ago

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!

smokinn• 17 years ago

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.

snprbob865• 17 years ago

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.

CitizenKane• 17 years ago

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).

steveklabnik• 17 years ago

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.

nathanwdavis• 17 years ago

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.

yummyfajitas• 17 years ago

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

Mnesia looks nice, but only for erlang...

jrockway• 17 years ago

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.)

leahculver• 17 years ago

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.

snprbob865• 17 years ago

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.

stcredzero3• 17 years ago

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)

ubernostrum• 17 years ago

This sounds familiar:

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

Dropping Django follow-up: Fundamental ORM flaw

Related Stories