Comments on: Be careful with the ‘local’ scope when migrating from CF8 to CF9

By: Michael Bragg

Michael Bragg — Tue, 06 Apr 2010 19:42:49 +0000

I too have been in the habit for years of using at the top of each function and pass almost everything around in this structure within each function, then pass that structure – or portion of that structure – out as a result.

In the process of upgrading a development box to CF9 (preparing to move the production machines to CF9) I found that some references to complex data types (nested structs, or a query in a struct) can no longer be referenced reliably ie: “local.query.recordCount” in CF9… this stinks. And it’s one of those “sometimes it works, sometimes it breaks” kind of bugs.

Changing the name of the “var-previously-known-as-local” to something else (like “result” or “my”) in the cfset fixes the problem. (Both are poor names to replace “local”)

BTW – I’ve applied the Hot Fix 1, still had the same problem until I renamed my “var’d variable”.

Now I just have to decide what is a suitable variable name to replace “local”, and fire up trusty old Dreamweaver to do a mass search and (delicate) replace…

By: Joe Hayes

Joe Hayes — Tue, 06 Apr 2010 17:02:53 +0000

See this post:
http://www.bytestopshere.com/post.cfm/major-flaw-in-cf9-may-break-code

…and the corresponding bug report:
http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=80621

Should be fixed under hotfix 1, but I haven’t verified (see bug 80621):
http://kb2.adobe.com/cps/825/cpsid_82536.html

By: Russ Michaels

Russ Michaels — Thu, 04 Mar 2010 17:34:52 +0000

What you probably do not realise as well is that using “local” to scope your variables also has other issues that exist prior to CF9.
If you store a query in the scope, e.g.

Then you can have problems working with this query while it is in this scope. It took me quite some time to work out why my queries were going screwy, but as a result I had to change all my scoping to LOCALS instead of LOCAL to resolve the problem.
I do not recall what the exact problem was as it was a couple of years ago, so wa son CF6 or 7.

By: Ben Nadel

Ben Nadel — Mon, 15 Feb 2010 17:21:50 +0000

Michael,

From what I heard from Rupesh Kumar, CFThread runs as a function call, so it might be getting confused between the two local scopes (the one inside the CFThread and the one inside the CFFunction). I’ll have to do some testing on that.

By: Dan Skaggs

Dan Skaggs — Tue, 09 Feb 2010 05:59:00 +0000

@lachdav You are correct, the variables you define are not put into the new local scope automatically unless you use the VAR keyword or assign them to local.x. Ray Camden wrote this post covering that very thing earlier today. However since my code was doing that should have created a Local.local structure. My return statement in those functions merely said cfreturn local which should have returned the entire local scope, not just my individual structure. The fact that it was sometimes returning the structure named differently was the key to the problem I was having. Once I changed from using "local" as my variable name to using "ret" the ambiguity went away and the application started working correctly again.

By: lachdav

lachdav — Tue, 09 Feb 2010 01:57:02 +0000

I may misunderstand what you’re saying, but I don’t believe the new ‘Local’ scope is implicit, nor are variables placed there by default. The default scope is still the Variables scope. To make a variable part of the Local scope, you either have to ‘var’ it or explicitly place it in the local scope (local.myVar = 123).

By: Michael Horne

Michael Horne — Mon, 08 Feb 2010 16:11:43 +0000

I was beginning to think it was just me! Totally unable to describe the error!

I’ve found another ‘gotcha’:
If you use CFTHREAD and within that tag you have references to the local scope (this includes functions called within the thread), the LOCAL scope is destroyed. You can literally have:

#local.wibble#

and under certain circumstances, wibble will be undefined in local!

Again, I’ve been searching for this error online but no-one else seems to have it.

It appears the local scope isn’t quite as safe as it seemed.

By: Dan Skaggs

Dan Skaggs — Mon, 08 Feb 2010 16:07:33 +0000

@Kev Yeah, that’s what I thought too. But I would have thought it would have failed every time that way, rather than the roughly 60/40 split I was seeing. The good news is that the fix worked, the bad news is that my testing regimen for moving sites from CF8 to CF9 is going to need updating.

By: Big Mad Kev

Big Mad Kev — Mon, 08 Feb 2010 15:07:10 +0000

Dan, off the top of my head I think if you code had the variable local set it would then set it as local.local. I remember some talk of this around the public beta.

Mr Forta has info on it here: http://forta.com/blog/index.cfm/2009/6/21/The-New-ColdFusion-LOCAL-Scope

“It’s clean, it’s simple, it’s intuitive, and it’s fully backwards compatible. And yes, if you have a variable named “local” it’ll still work, the variable will just become LOCAL.local, and as the LOCAL scope is in the default evaluation chain it’ll just work.”