ColdFusion updated, and some notes about query caching

This post is more than 2 years old.

Earlier today the ColdFusion team released a big update for ColdFusion 11 and 10. You can read the juicy details here: ColdFusion 11 Update 3 and ColdFusion 10 Update 15 are available now. While looking over the release notes for ColdFusion 11, I saw this odd little gem:

Below caching functions now accept object instead of String parameter for CacheId attribute: 1) cacheGet
2) cacheRemove
3) cacheGetMetadata
4) cacheIdExists

That seemed.... weird. So I went over to the ColdFusion docs for cacheGet and was disappointed to find that no one had updated this. When you make a change to the language, you need to update the docs as well. Release notes in an update are not enough. I'll raise this internally so hopefully it won't happen again. There is also the corresponding need of an update for ColdFusion Builder. I'd have to assume (and I can definitely be wrong!) that this language tweak would require a minor update to CFB, so that should have been released as well. Again, I'll raise this internally.

So what is this change about? I looked at the "Issues Fixed" document (PDF link) and discovered bug 3741588. Oh, if you click that link and end up back the bug tracker home page... yeah that's a bug. Click it again. (sigh)

From what I can read in the bug report by itisdesign, at some point there was a change for queries that were cached using cachedWithin/cachedAfter. If you do not specify a specific cache ID for the query, then a Java object is used for the ID instead. Here is an example.

q = queryNew("id", "cf_sql_varchar", [{id:"a"}, {id:"b"}]);
q2 = queryExecute("select * from q", {}, {dbtype:"query",cachedwithin:createTimeSpan(0,0,1,0)});

q3 = queryExecute("select * from q", {}, {dbtype:"query",cachedwithin:createTimeSpan(0,0,1,0),cacheId:"mystuff"});

ids = cacheGetAllIds("QUERY");

In the code above, I'm caching two queries, but I only specify a specific ID in the second one. Notice the result when I dump the IDs:


Yep, a complex object. So the change is to allow this object to be passed as an ID value to various caching functions. Makes sense I suppose but wasn't obvious to me. While investigating this I came across this document (Enhanced query caching using Ehcache) that talks about how queries may now be stored in fancy Ehcache versus ugly old school cache. This happened back in ColdFusion 10 and I knew it, but while reading it I discovered two new Application.cfc variables I had not heard of: cache.useInternalQueryCache and cache.querysize. These are not listed on the wiki so I fixed that: Application variables

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Mark Kruger posted on 12/9/2014 at 9:28 PM

Ray, just to be clear, you mean you can pass EITHER an object OR a string? Or has it switched from string over to object only? One would be a nice (though undocumented) plus, the other would require some refactoring wouldn't it?

Comment 2 (In reply to #1) by Raymond Camden posted on 12/9/2014 at 9:30 PM

Sorry, both work.

Comment 3 by Tom Hubbard posted on 12/10/2015 at 5:02 PM

Is there a way to get a handle on a QueryDetails object of a given so that we can remove it from the cache?

Comment 4 (In reply to #3) by Raymond Camden posted on 12/10/2015 at 6:57 PM

Not sure. Of course, the easiest solution is to just provide an ID.

Comment 5 (In reply to #4) by Tom Hubbard posted on 12/10/2015 at 7:53 PM

The problem with using ID is that it doesn't separate the queries based on the content of the sql/parameters.

When using just just cachedwithin, a new cache entry is entered for each sql/parameter combo.

A solution is to make the ID reflect the parameters to keep it distinct but, it would be nice...

Comment 6 (In reply to #5) by Raymond Camden posted on 12/10/2015 at 8:22 PM

Oh I just figured that was assumed. :) I used to serializeJSON(arguments) as a quick and dirty way to make a hash.