On Sat, Oct 1, 2011 at 1:18 AM, Sean Corfield <[email protected]>wrote:
> I think this would be a terrible idea. I think Adobe made a big > mistake adding Hibernate ORM to ColdFusion and I think the Railo team > have had to waste a lot of cycles on implementing it that could have > been spent on features that would benefit more users. > Thanks so much for sharing Railo's experiences Sean. As you can imagine we've debated this but to most of the steering committee the cost/benefit analysis doesn't come out favorably. If nothing else, people should take away from these discussions that ORM is a tool like any other, and to use it effectively you have to get your hands dirty despite all the sales pitches to the contrary. It's not a silver bullet. The typical progression I've seen as people start getting into ORM is that it's great for simple little apps you use to get familiar with the tool. Then you start doing more complex things and you have to actually learn the tool, not just blindly throw stuff at it. Then you wonder why it's behaving the way it is (you can EASILY shoot yourself in the foot doing things that *seem* perfectly logical in Hibernate), so you dig in more and learn all the tool's quirks. Then you run into situations where you have to write your own XML files because the default stuff doesn't work, and wrangle with the default Hibernate session behavior because it won't work for your situation, and write HQL because Hibernate won't quite do what you need it to do ... and then you start thinking maybe writing your own SQL ain't all that bad. The other issue is that you're using ORM ostensibly to save development time, and in exchange your application takes a performance hit at run time. That's never seemed like a good trade-off to me. http://www.iheavy.com/2011/08/26/5-things-are-toxic-to-scalability/ And be SURE and read the "ORM is the Vietnam of Computer Science" link Sean provided. Required reading if you're even considering using ORM. All this being said, I'm sure there are people using ORM effectively once they learn all the quirks, or maybe some people tend to write apps for which ORM is perfectly suited, but if anyone is thinking "oh if I just had ORM I'd cut my development time in half and never have to think about persistence again," you're sorely mistaken. ORM is a big, hairy, complex problem to solve and even with a best-of-breed tool such as Hibernate, if you do decide to use it you better buy a couple of the big-ass books on it (Java Persistence With Hibernate is an excellent one) and learn the tool inside and out. If you don't you may find yourself left holding an unpleasant-smelling bag either during development, or worse, when your application goes into production. And this is true for every app ORM or no, but if you DO use ORM *for crying out loud load test your application*. I've heard way too many horror stories from people who build an app around ORM with small datasets and it works great in development, then they go into production and it's slow as hell, they start getting out of memory errors, they realize that some seemingly logical ORM operation they're doing pulls back everything in their database ... The best way to not have to write SQL for your applications? Use a NoSQL database. :-) Totally different topic but I've been using CouchDB a great deal lately and that actually *removes* the object-relational impedance mismatch as opposed to giving you a complex tool to deal with it for you. That to me has felt like a huge weight lifted off my applications, whereas ORM never felt that way. Or if you do your homework and decide you love Hibernate you can write your model in Java. Ultimately that'd probably give you far fewer headaches. -- Matthew Woodward [email protected] http://blog.mattwoodward.com identi.ca / Twitter: @mpwoodward Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html -- official tag/function reference: http://openbd.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
