[Looking for Charlie's main web site?]

Spying on ORM database interactions: Hibernate, Transfer, etc. on any CFML engine

As people use CF9's ORM feature (or other ORMs like Transfer and Reactor, or indeed Hibernate, on any CFML engine), they may be left wondering what sort of SQL interactions happen "under the covers" between the ORM framework and the database engine. Well, there are several ways you can watch them, as this entry will discuss, and it may be interesting to discover what's going on.

Of course, ORM support is just a different way that the CFML engine (through the ORM framework) sends SQL to a database via a regular DSN, just like any other request, so there's nothing really "tricky" about this. It's just about realizing that while you don't write the SQL yourself, it's still generated by the CFML engine/ORM framework, and you may not realize/consider the available tools which can spy on it, just like any other DB processing from within CF. Indeed, some people may not even realize how many options exist to spy on JDBC interactions from their CFML engine to the database engine.

The good news is that there are several approaches, some included in CF (some depending on the edition), and some available separately which would work in any edition of CF or the other CFML engines (Open BlueDragon, Railo, etc.), and with any of the ORM frameworks.

(FWIW, besides the aforementioned Transfer and Reactor, there are still others, which I mention in my CF411 list as CFML ORM Frameworks. Indeed, note that you can run Hibernate on CF prior to CF9.)

Built-in ORM Logging Option

Update: After posting this entry, I learned that there's yet another option, so I'm adding it here as the first to consider. There is a built-in option in the CF ORM setup where one can enable logging, settable in the application.cfc: see the this.ormsettings option and its available key/value pair, logSQL="true".

There are several resources where you can learn more on that. Besides the CF9 docs page on the ORM settings, there is also a blog entry by Adobe engineer Rupesh Kumar. I've not yet used it, so don't know how it compares to the other options below. I will leave them for all to consider.

Using FusionReactor or SeeFusion

Users of any CF edition (6+) or CFML engine can use tools like SeeFusion and FusionReactor, which have always had the ability to monitor database interactions by "wrapping" the datasource to be monitored. FusionReactor engineer John Hawksley has posted a recent article specifically on monitoring CF9's ORM interaction, in the FR Devnet site, Using FusionReactor's JDBC Driver Wrapper With ColdFusion 9 ORM. Its concepts would apply to any ORM, of course.

Similarly, I've written generically about its database monitoring feature in What is the FusionReactor datasource monitoring feature? Why would I use it? Powerful stuff. As I point out in that article, the concepts discussed apply as well to SeeFusion's ability to monitor queries by wrapping datasources.

CF Enterprise, with a caveat

I also mention in that article that those running CF 8 (or now 9) Enterprise will find that it has built-in wrapping of datasources, such that its Enterprise Server Monitor reports database interactivity, so that can also monitor the ORM interactions.

A key difference for FR and SeeFusion over that, though, is that while they all have means to highlight queries that exceed certain limits, only FR and SeeFusion have the built-in ability to log every DB interaction (FR to text logs and SF to a database, and they both do so with low overhead). The CF Enterprise Server Monitor has no logging ability at all, and while you can set its interface to lower the threshold for what active queries to show, it has no means to show queries which have executed in the past.

It's just that it can be useful sometimes to see every single DB interaction for a request (or all requests), and it may be all the more interesting for discovering/observing what's happening with ORM interactivity.

Another alternative CF feature

Still another little-known feature for spying on JDBC interactions in CF is by way of the JDBC "spy" feature, which does in fact allow logging of all JDBC interactions mde from within CF. This feature was first enabled by way of the DataDirect 3.5 driver update which was made available (as an optional upgrade for 6 and 7) in the CF 7.02 timeframe. I wrote about the Spy feature back back in Aug 2006.

Since then, CF 8 (and now 9) offer it instead as a new "log activity" option in the "advanced settings" for a datasource definition in the CF Admin (which is disabled by default). I pointed this out in another entry from 2007 as one of many easily missed changes for the CF 8 Admin.

This "log activity" output is not as easy to interpret as FusionReactor's logs, and can indeed be voluminous (moreso than FR's), so be careful. Anyway, it's one of the several ways you can monitor JDBC interactions between CFML and your DB engine. Again, any of these may be useful for monitoring any of your CFML/database interactions.

Generic DB Monitoring tools

Indeed, it's worth noting finally that while the focus here has been watching the DB interaction from CF (and the ORM framework) to the database (by watching the JDBC traffic going out of CF and returning), you could just as well watch the DB interactivity from the DB's perspective instead (watching it coming and and being returned).

There are many tools that can monitor database processing, available for each of the major databases (free and commercial). I list several such tools in one of my CF411 section, Database/SQL Monitoring Tools.

Hope all that's helpful, whether you use ORM or not.

IBATIS as a possible new approach to object-relational mapping for CFML?

I'd like to put out for consideration by the CFML community a possible new approach for object-relational mapping (ORM), using an existing Apache project called IBATIS as a model. I'm wondering if someone may want to consider implementing a CFML version of it for a new ORM approach in CFML.

IBATIS, at http://ibatis.apache.org/ is an alternative ORM approach based on a concept of SQL Maps, which in essence are simply SQL statements stored in XML files with a well-defined API for mapping and manipulating those in your app. The approach does not generate SQL for you, but rather is intended to serve as a means to segregate to XML files--and manage via an API--the SQL that may already exist substantially for existing apps or for new apps that may simply require some hand-coding of SQL. (The last sentence added after some comments suggest that this point made later in the post was missed.)

The benefit is that since CFML folks are already knee deep in SQL, it brings a measure of architecture without completely detaching them from the SQL they know and love (or at least tolerate).

If that sounds counter to other ORM approaches, which often generate the SQL automatically and/or intentionally hide it from you, that's because it is quite different. I'll grant that there are many who would benefit from having an architecture remove SQL from their control. It's just that this seems an alternative worth considering.

I certainly don't mean to knock at all the other CFML-based ORM implementations that exist already (such as Arf, ObjectBreeze, Transfer, and Reactor). Each approach has its place and pros/cons. As the other CFML-based ORM frameworks tend to be based on existing approaches from other platforms, I'm merely pointing out this alternative as a possibly useful model.

I'm also not offering here my own new CFML-based implementation based on IBATIS. But note that there are currently implementations for Java and .NET at the Apache site, so it shouldn't be tough for someone to leverage the Java implementation in CFML.

It strikes me that the IBATIS approach may be closer to the way fuseboxers and others segregate their queries into their own CFML file. Perhaps this approach of storing them in an XML file instead and using an API to access the results would offer a better though still somewhat familiar approach to abstracting queries.

I was sharing the idea with Sean Corfield at CFUnited last night, and he was intrigued. After I sat in on his excellent presentation on objects and persistence, we discussed it again and he had started looking into it overnight. Perhaps it could make it into FB 6? :-)

I'm hoping someone may want to take the ball and run with it. If you're intrigued, considering discussing it with Sean or take it on yourself, or just continue the conversation. Hope it proves helpful.

BlogCFC was created by Raymond Camden. This blog is running version 5.005.

Managed Hosting Services provided by
http://www.edgewebhosting.net/
Managed Dedicated Hosting