CFArgument: Hibernate or Hiber-NOT :-)

Brian Rinaldi
As you well know, the ColdFusion team has discussed its intention to include a built-in ORM in ColdFusion 9 that uses Hibernate. As Hibernate is the 900 lb. Gorilla of ORM's, this makes sense. Obviously, a lot needs to be known about how they decide to implement this, but overall this sounds like a potentially very strong addition to the language and I, for one, am excited about it.

Peter Bell
I love Hibernate and I would love to be able to take advantage of it in ColdFusion, but I think the Object Instantiation Penalty in ColdFusion is going to severely limit the value of Hibernate integration. Most CF devs use cfquery to return collections instead of arrays of objects because of real and valid performance concerns. So my biggest concern about Hibernate is that we're going to have to drop down to Java or Groovy objects to be able to take advantage of it for the ORM layer.

Brian Rinaldi
Agreed. The penalty for creating objects in ColdFusion 8, while improved over prior versions, is a serious drawback. I recognize this most significantly when I am working with Flex and hacking around to return typed structures as opposed to arrays of objects just to eliminate this penalty. Nonetheless, I think these are actually two separate, though possibly related, feature/improvements we'd like to see in Coldfusion 9 (on that mark...its time for null...but I digress).

My question for you Peter is, assuming they improve the penalty, do you have objections to Hibernate integration? Any concern about how the configuration will be managed?

Peter Bell
I agree that there is a general need for speeding up object instantiation, but my concern is that it'll be 20% faster in CF9 whereas I think we need to see it being 3-5 times faster to be able to work with objects in the way you would in a language like Java or even Groovy. There is little point having a real ORM in a language that doesn't allow you to use objects across the board while still performing acceptably in production.

As for general objections to Hibernate integration, it'll depend upon details of the implementation that haven't been fully released. Effectively it looks like we'll be able to add metadata to classes and to cfproperty tags to define persistence concerns for Hibernate. I think that is a great way to go, and the idea of making the hard (ORM) easy via ColdFusion is a great one. My concern is how will we extend the basic annotation metadata when we need to do something a little more complex.

As long as the implementation isn't based on passive generation of XML config files that (if we manually edit them) won't be available for regeneration as we update our cfproperty tags then we'll be fine, but merging generated and custom data within XML files by doing stuff like merging DOMs is a non trivial problem (as anyone who has ever tried to merge generated and custom MXML has found out). I'm just hoping the CF team has been paying attention to what's going on the the Domain Specific Modeling world and things like model to model transforms and XML merges so that we don't end up with lame passive generation which would be very 1999 :-)

Brian Rinaldi
Right, I can't imagine it will be passive generation. Though, some of the hints so far have seemed to imply that you can use the metadata approach or manually edit the configuration files if you are comfortable with Hibernate. I can see that could become problematic.

Peter Bell
That is exactly what concerns me. If we're talking about editing generated artifacts then we're going to be limited to simple apps that can be described in ColdFusion or we're going to have a maintenance nightmare where any customizations either get overwritten or (just as bad) stop updates in ColdFusion from being saved to the hibernate config files.

Brian Rinaldi
As for the object instantiation, it will also depend on the implementation. If each object in an array of objects faces the same penalty as in the current version of ColdFusion, then it will be a major drawback.

Peter Bell
Agreed. And it is important that we get *real* objects. Things like pulling support for onMissingMethod() would be problematic. I'm also interested to see what kind of support the Hibernate created objects will have for integration with ColdSpring or LightWire for Dependency Injection. If I want to inject a validation singleton into all of my User objects returned by Hibernate, how will that work? Also, will I be able to implement ColdSpring AOP on the beans I get back from Hibernate? Answers to these kind of questions will have a huge impact on the value of Hibernate integration for real world projects.

Brian Rinaldi
Though, with that being said, we face this issue with existing ORM's in ColdFusion and they are still useful. Also, assuming this all integrates as nicely with Flex as I imagine it will, it will be a huge boon for rapidly building back-ends to Flex applications and could be a great selling point to companies adopting Flex.

Peter Bell
I think the reason that Transfer and Reactor work is because as CF developers we typically have very simple object models. One of the benefits of Hibernate is that it can support richer object models. In CF, we'll often just have an Order object in an e-commerce application. With Hibernate it might be more tempting to add an Address value object for encapsulating the behavior inherent in the BillingAddress and ShippingAddress fields persisted within the tbl_Order in the database. Once we start doing this, the demands for object creation are going to be more intense and I'm concerned that another incremental increase in object instantiation performance won't be enough to solve the problem.

I also think that ColdFusion integration with LCDS, BlazeDS and Flex is key for a lot of companies, and if we can use ColdFusion to create enterprise ready apps with Hibernate and Spring under the hood that'd be amazing. I just hope that the simplicity which CF provides won't come with an unacceptable performance penalty that might make Groovy/Grails a more attractive option for Flex back ends.

Brian Rinaldi
I suppose in the end it all boils down to how it is implemented and considering this is, in my mind, one of the most important features in ColdFusion 9, one hopes it will be implemented well. Now, while they are at it, can I put in a side note about ending the uppercasing of structure keys (particularly in the new implicit structure syntax) and adding support for null, so I don't have to work around null values when passing/getting data with Flex. Sorry, had to get that in there, its what is annoying me right now.

Peter Bell
LOL, clearly this is becoming CF_Argument, the Centaur wishlist edition! To summarize, I am excited about getting an enterprise level ORM built into ColdFusion, and I think it perfectly supports the ColdFusion mission of making hard things easy. I hope that the implementation is rich enough to cover most use cases, that the extensibility is based upon some form of active code regeneration pattern, and that performance concerns don't derail what could be one of the most important features to come to CF in years.

Brian Rinaldi
I think we are in agreement. I share your concerns. While I think they are on the right track, I think the two year release cycle often forces these features to get pushed through before they are 100%. So, I am concerned that a feature of this scale and importance might not get perfected until ColdFusion 10 though I suppose there could be a a mid cycle point release...but here's hoping they get it right straight out of the gates!

As usual, you win the volume of words contest! :)