Ok, I know this sounds crazy, but yesterday I encountered a bug. What makes this more crazy is that the code worked locally on a development machine but not production. Now I know that hasn't happened to any of my readers, but it actually happened to me twice in the past 24 hours, and in both cases it was the same issue - although expressed in slightly different ways.
The code in question was a very simple CFC method:
remote boolean doX(numerid x) {
return x > 1;
}
That isn't the exact code I had, but if you look closely you can probably see the bug already. I was using the CFC method in a simple Ajax application (this one...) and everything worked fine on my local server. Once I pushed the code to production, though, I got an error about my argument not being of type numerid.
Numerid? WTF?
Yep - I had typoed (or as I call it, pull a Zoid) numeric. So why did it work locally? One of the options in the ColdFusion Administrator is Disable CFC Type Check, which is explained as: When checked, UDF arguments of CFC type is not validated. The arguments are treated as type "ANY". Use this setting in a production environment only.
Right away you can see one mistake. The setting clearly says it should only be enabled in production. I don't even remember turning it on but I guess I did. Now this is where things get interesting. When it comes to UDF arguments, the type you specify can be anything you want, but if you specify a value that is not on the list of defined types (like numeric, string, etc) that ColdFusion assumes you mean a CFC type. In my case, numerid ended up, to ColdFusion, implying some CFC named "numerid.cfc". Because I had "Disable CFC Type Check" on, it ended up being Any, which means I could pass anything I wanted to it - CFC or not.
Ok, so to be clear - that isn't a bug in ColdFusion. That was definitely my fault. But this is the first time that setting has tripped me up like that. Of course, to make things fun, I tripped over this exact same issue again today, this time in regards to ORM. I had used this code in a persistent entity:
type="nvarchar(10)"
What I had meant to do was
sqltype="nvarchar(10)"
Type in cfproperty refers to the same list of types we use with UDF arguments. Once again - since I had picked an unknown value, CF assumed I meant a CFC, and because I had the "Disable CFC Type Check" setting on, it just plain worked for me.
Archived Comments
So, why should this setting only be enabled in production? It seems like you would want it enabled in both.
You don't think this blog post is a good example of why it is bad for it to be enabled in dev? :)
Sorry, let me clarify. Why would you disable the type check? Is it just resource intensive and therefore you may not want it on in your production environment?
Yes, it improves performance, but I don't have hard and fast numbers to back that up. I don't worry about it typically. Trusted Cache is what I normally use on production - that's a night and day difference typically.
@Daniel,
That's exactly it. There is some overhead involved in performing the type check. I haven't actually seen anyone run any performance tests to see the actual impact though.
I don't know if this is the reason, but type-checking happens at runtime in CF which means that that you will take a bit of a performance hit:
http://www.google.com/searc...
Of all the ColdFusion caching paradigms available to us Trusted Cache or Template Cache is the easiest to use and the most predictable and effective. In CF8 and 9 it got even easier to use as we can clear it from inside CF Admin. Thanks for the post Ray I am sure it will help many.
I've definately seen some noticeable performance improvements in disabling it, specifically when testing under load. As Joe mentioned, the type checks happen at runtime, rather than compile time.
Best practice is to keep it enabled on dev environments (to catch type-related errors) and disabled in production.
I enable it in dev to keep development tight, but turn it off in production in performance. If the code on dev is passing the correct data types then in theory it will continue to work in production and the check is unnecessary. I beleive I started doing that after listening to a user group preso by Michael Dinowitz.
I'd love to see a blog post ( or presentation? ) on the real impact on performance using the trusted cache can make and at what scale.
Most of the time it is _immediately_ visible. Try turning it on a production system and I'd be shocked if you don't see a change -a HUGE change.
Oh my Todd in heaven. You weren't kidding.