Month: September 2009

I got a question today:

I was wondering if you could blog on the advantages with CF9 ORM using Hibernate versus something like the Active Record pattern Rails uses? I am not too familiar with Hibernate but go through Rails Envy once in awhile 🙂

This is an awesome question, and I’m going to tackle it, but I’m going to break it into a few sub questions. Before I do that, this is comparing apples to oranges. Active Record is a pattern and Hibernate is an ORM solution that uses a pattern named Data Mapper. I can’t speak to the entire reason for choosing Hibernate, as I’m not one of the engineers, but a quick survey shows it is the leading ORM solution in Java right now, which pushed us that way.

What are the differences between Data Mapper and Active Record?

The underlying one seems to be a philosophical one:

• Data Mapper looks to the objects to be the definition of the data; the database is just a place to store it.
• Active Record looks to the database to be the definition of the data; the object is just a way to access it.

   

That’s an oversimplification I’m sure. Data Mapper requires you to map out each table and each column. Active Record by and large will detect things like tables and columns for you and expose them. Implementations of both patterns include the ability to tweak the configuration, but it looks like most Data Mapper implementations need to be configured. (As opposed to Active Record implementations like Rails that prefer convention over configuration.)

A practical consideration that occurs is that Active Record objects handle talking to the database with load, save, and delete methods; while Data Mapper objects get passed back to another object or function to translation back to the database.

There are also issues about performance and mapping. I won’t bother going into these as they are issues with implementation of the pattern and not the pattern itself.

Why did you go with Data Mapper over Active Record?

Two major reasons here:

1. Hibernate uses the Data Mapper pattern
2. Because the community (represented on the prerelease site) by and large asked for it.

I don’t remember the entire rationale behind this preference, but I will push responsibility on to the prerelease testers. 🙂 I think it is related to the two next issues.

Is ColdFusion ORM pure Data Mapper?

Not necessarily. Sure you create CFCs with properties. You then use the Entity functions to save them back to the database. You can have those properties actually create and update your database structure. That is clearly Data Mapper in action.

However, you can leave all of the properties in your CFCs blank, and ColdFusion will just populate it from the database. You can leave some of the details of your properties blank and ColdFusion will make assumptions about how they’re typed. These are philosophically Active Record features.

It comes down to ColdFusion making stuff easier, regardless of underlying philosophy. ColdFusion does both, to facilitate both database-focused and object-focused ORM implementations.

Can you create Active Record CFCs with ColdFusion 9’s ORM?

Yes. You can wrap the Entity functions in a CFC like this:

<cffunction name="save" access="public" returntype="void">
 <cfset EntitySave(This) />
</cffunction>

 
Once you do that you can call your objects using the active record pattern of object.save(). In fact Bob Silverberg has started work on an Active Record CFC that you can just have all of your CFCs inherit from called Base Persistent ORM Object (Active.)
	
So hopefully this answered some of the questions around Hibernate, the Data Mapper pattern and the Active Record pattern in ColdFusion 9.  
		

ServerFault.com, a Server Administrator centric companion to StackOverflow.com, has a ColdFusion section. I’d love to see the greater ColdFusion community jump in here, and help if they can, and find help if they need it.