I have never used ORM and I’m researching reasons to try it. The documentation for Lucee ORM seems to indicate Cons outweighing Pros. Most important to me is performance, which seems contradictory:
Pros
Cons
So, which one is it?
Im in my experience, and again I like tags (Way old school here) ORM works well in modern newer style containerized apps that scale based upon some other api metric and, are well thought out and written. Example, works great in a hadoop or azure datalake setting for an app that was designed to hold tractaional data.
Use ORM if resources are not an issue (You can throw money at it and the problem will go away)
However, I leave it as this.
ORM should not be, the base design of any application. If you can, do it traditionally as native applications written specifically for a database or file structure are faster, have less overhead and overall are less prone to leaving you gnashing your teeth for hours on end staring at multiple debuggers looking for what is breaking.
Just my take, again, My applications tend to be “old school”.
Hi, Jennifer. I’m sure you will hear differing opinions. 
More on that in a moment. But I’ll share a few of mine (from more of a troubleshooting perspective) that may perhaps help as you contemplate this feature.
1) The range of opinions
Let me say first that with orm being an abstraction layer, there’s always the chance that people will find it mysterious and make such pronouncements–even contradicting ones, as those in that doc do. (I’ll share in a moment how to better understand what’s really going on, rather than leave things such a mystery.)
It can also lead others to dismiss ORM in general as not worth the effort, while still others will regard it as THE way to go. Witness the site and resources of https://vladmihalcea.com/, who makes a living helping people make the most of orm (aka “persistence”) and hibernate in particular (which underlies most Java orm, as in ACF and Lucee).
The truth and typical experience of using it lies somewhere within that range.
2) The value of monitoring orm
But I can add second that good monitoring of what is really going on “under the covers” in orm can REALLY help you to know first WHAT sql is being generated. A tool like fusionreactor does this best in the context of a cfml web app, as it shows the top slow sql for every request (including those generated by orm), and it can even log those or log every one. But there are free and simplistic tools and logging features that some may consider/recommend instead.
Beyond knowing WHAT sql is being generated, note also that the sql then runs in your database just like any you’d craft by hand. And just as with those, we’d be helped tremendously with some sort of monitoring in the db server, to understand WHY it may be slow. That may lead to improvements in the db or in how the orm feature is configured to generate its sql.
3) Finding more documentation on orm, especially from CFML
And finally that’s another area where some are not aware: while we can “just use” the orm feature rather blindly, there is indeed a lot you can tweak about it, whether in your code, in your application.cfc/cfm, or in the underlying hibernate config.
And that takes us back to deeper discussions of the topic at sites like Vlad’s above, or even the acf docs (the Developing Applications manual rather than the cfml Reference).
You’ll also find more discussion of orm use within cfml in the context of various tools and projects of Ortus Solutions.
As I hinted at in the open, this is a topic like many in Lucee (and CF and IT in general) where “opinions are like noses”. More than that, it’s like discussions of frameworks, where often those writing about them speak more to those who DO already understand the motivation for them–such that they tend to leave that out of their discussions or documentation.
And the Lucee docs fall into that trap sometimes regarding cfml features, with a presumption that readers are coming from acf–such that the focus is on any differences (advantages or gotchas). They tend not to point to what even may be substantial additional documentation on a topic.
4) Improving the Lucee docs
That said, the Lucee team are always open to the docs being improved, whether to correct such a typo or to add more context, or (I assume) to ads links to more on a topic (though some doc folks prefer NOT to link out to such references, whose links may change and break over time).
Hope some of the above may help you. And let’s see what others will offer.
I’ve used ORM quite a bit and find it really useful in areas of an application where there is a form editing a single record at time. (I like working with objects)
When searching large databases I tend to stay with SQL and maybe load a paginated result set of objects from that query depending on what the needs of the application are.
I’ve also used Mongo quite a bit for the same kind of Object/peristence layer. (Querying Mongo comes with case sensitivity)
I tend to find apps built with an object persistence layer like ORM easier to digest and figure out when inheriting someone else’s app … because you’re usually left with someone else’s personal interpretation of how to build a persistence layer or framework.
ORM can be difficult to decipher when it’s throwing errors. Relational Mappings take awhile to figure out compared to SQL joins.
Related to “performance” the Lucee docs maybe alluding to, if a developer tries loading 1000 HQL objects instead of 1000 SQL records there will be a performance hit.
Hope that helps
I’ve been working on and off on migrating a large application from ACF to Lucee over the last year. This has made me acutely aware of some major cons around using ORM, so please take my thoughts with a grain of salt.
IMO, I’d focus on an ORM library with fewer drawbacks such as Eric Peterson’s Quick.
I thank you all for your helpful replies!
I’m leaning towards taking a pass on ORM, especially after skimming Yegor Bugayenko’s analysis from 2014. He presented an alternative called SQL-Speaking Objects. Other factors for me are that I’m totally comfortable with SQL and I have a preference for OOP in general.
It’s a lot to digest and I haven’t even finished reading it all, but I also found a more recent summary by Mikhail Yakushin:
The simplest explanation for this is that the lead developers of Lucee have never been big fans of Hibernate and didn’t use it themselves, which no doubt influenced both the docs on the matter and the fact that CFML ORM is known for being buggy, poorly documented, and difficult to get working.
ORM does tend to be polarizing and it’s popularity seems to reflect how well the core engine supports it. Take Ruby on Rails or the Grails communities-- they have very high usage of ORM and its viewed positively. It can be a bit of a redheaded stepchild in the CF space due to lack of great vendor support and few community champions.
I have a love-hate relationship with it-- it’s great when it works and annoying when you’re dealing with some oddball Hibernate error, or a bug in the CF engine. There have been a few ORM libraries written in CFML over the years. The only one still active is Quick, which is a functional approach borrowed from PHP Eloquent library. It’s not as robust as Hibernate, but it does get bug fixes sooner and is independent of any CF engine version.
If you’re new to CF in general, I’d recommend just playing with the language and frameworks for now and hold off on ORM. It has its own steep learning curve to adapt to.