Object-Relational Mapping is the Vietnam of Computer Science

   * we use Python+MySQL
   * each table has an associated class, a CRUD-API if you will
   * a cursor object accesses a table like this:
    cursor.TableName.select_by_ids(low, high)
   * removing means set time_removed to the current timestamp
   * rows are returned as lists of dicts

So the solution to the object-relational mapping problem is: for each table, there is a class that manages access to it, and a row is represented by a a dict.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#6

Post by wyw » Sun, Aug 23, 2009, 7:57 PM UTC

Virax wrote: post #5

Talk about making a mountain out of a molehill. At my company, we don't try to turn database rows into objects. Here is how it works: * we use Python+MySQL * each table has an associated class, a CRUD-API if you will * a cursor object accesses a table like this: cursor.TableName.select_by_ids(low, high) * removing means set time_removed to the current timestamp * rows are returned as lists of dicts So the solution to…

How do you map the types if the rows are returned as dicts? Doesn't that become an application responsibility? By using an ORM you would not need to build that functionality, i.e. reinvent the wheel.

Did you consider using SQLObject or SQLAlchemy? If so, I'd be curious to know why you decided against using them?

Re: Object-Relational Mapping is the Vietnam of Computer Science

#7

Post by jhancock » Sun, Aug 23, 2009, 8:01 PM UTC

I agree with Atwood's conclusion here. If you must use both an OO second tier and a RDB 3rd tier, concessions must be made. You can get around most concessions with more code at the hard parts, but sometimes its just not worth the effort. In addition to these concessions, there have been choices of OODBs for quite a while. We are now seeing some new DB choices come on the scene.

My perspective comes from having written what may have been the world's first ORM in Smalltalk in '88. I then spent the next 14 years building them over and over along with a full stack of other frameworks in Smalltalk and Java. Choices must be made. No framework is one size fits all. I generally sided with "make the easy things easy/automated and make the hard things possible/maintainable".

Is it Vietnam? No. You have far easier choices in how to develop your app than soldiers did in choosing wether or not to go to Vietnam. I wrote very hard ORM and other framework code; solved problems that enabled my customer's projects to be far more productive; was paid very well; enjoyed a good life; worked hard and was respected for my contributions. Hardly Vietnam.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#8

Post by wyw » Sun, Aug 23, 2009, 8:05 PM UTC

jhancock wrote: post #7

I agree with Atwood's conclusion here. If you must use both an OO second tier and a RDB 3rd tier, concessions must be made. You can get around most concessions with more code at the hard parts, but sometimes its just not worth the effort. In addition to these concessions, there have been choices of OODBs for quite a while. We are now seeing some new DB choices come on the scene. My perspective comes from having writt…

I think the comparison to Vietnam makes sense as an analogy.

The basic argument seems to be that each ORM imposes limitations specific to that implementation which may result in the developer's choices being limited later on in the development process - just as early strategic decisions in a war can predetermine the outcome and potentially result in 'quagmire'.

It's an argument that seems to echo Joel's idea of "leaky abstractions", i.e. the ORM is just a big leaky abstraction and you have to deal with the leaks sooner or later.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#9

Post by jhancock » Sun, Aug 23, 2009, 8:06 PM UTC

wyw wrote: post #6

Virax wrote: post #5

Talk about making a mountain out of a molehill. At my company, we don't try to turn database rows into objects. Here is how it works: * we use Python+MySQL * each table has an associated class, a CRUD-API if you will * a cursor object accesses a table like this: cursor.TableName.select_by_ids(low, high) * removing means set time_removed to the current timestamp * rows are returned as lists of dicts So the solution to…

How do you map the types if the rows are returned as dicts? Doesn't that become an application responsibility? By using an ORM you would not need to build that functionality, i.e. reinvent the wheel. Did you consider using SQLObject or SQLAlchemy? If so, I'd be curious to know why you decided against using them?

There are lots of ways to do this. A most common approach is to have each of those dicts be a first class object in python/blub, and therefore you know the class of the object. Customer.find() returns a customer which contains your dict. No magic going on here. You are not reinventing too much by deciding to use lightweight wrappers and eschew automated SQL generation or ORMS and related DSLs.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#10

Post by jhancock » Sun, Aug 23, 2009, 8:11 PM UTC

wyw wrote: post #8

jhancock wrote: post #7

I agree with Atwood's conclusion here. If you must use both an OO second tier and a RDB 3rd tier, concessions must be made. You can get around most concessions with more code at the hard parts, but sometimes its just not worth the effort. In addition to these concessions, there have been choices of OODBs for quite a while. We are now seeing some new DB choices come on the scene. My perspective comes from having writt…

I think the comparison to Vietnam makes sense as an analogy . The basic argument seems to be that each ORM imposes limitations specific to that implementation which may result in the developer's choices being limited later on in the development process - just as early strategic decisions in a war can predetermine the outcome and potentially result in 'quagmire'. It's an argument that seems to echo Joel's idea of "lea…

The arguments in Atwood's and Neward's articles stand well on their own. The war analogy is there as link bait.