Hello folks,
I have recently been scoping all the variables in my hobby project; although, I am unsure what scope cfquery tag names fall into. would it be variables?
<cfquery name="variables.myQuery"> .....
<cfdump var="variables.myQuery"/>
inside a function, you could just use the local scope, i.e local.myquery
there’s some good info here
https://lucee.daemonite.io/t/optimizing-your-code-scope-cascading/428
2 Likes
Hi Zack,
Using your performance analyzer plugin this week, I noticed that Lucee 5.3.6 is looking for (and finding) my queries in the variables scope, even though I name them as so:
<cfquery name="local.myQry">...
I don’t use a cfset before the query to declare the name and scope, though. Should I?
are you in a .cfm or a function?
CFC method (function).
More testing: even when I add a <cfset var qryName="" /> <cfquery name="qryName" ...> I still get entries like this:
base.cfc 313 cfquery variables 157
Interestingly, I don’t see any entries when the (inherited, antique…) code has this before a cfquery:
<cfset var qryName = queryNew("") />
But, the performance wastage of queryNew is distasteful to me to adopt it widely.
it’s unfortunately for backward compat, use can always localmode=true or
<cfset var cfquery=""> or <cfset local.cfquery="">
we are seriously considering disabling this behaviour by default for Lucee 6.0 with an application setting to renable it
Wait, I am confused. Is @mgatto saying that var’ing the query name inside of the cfc method is NOT enough and Lucee is placing it in the variables scope anyway? However, setting the var query name to a blank, new query via queryNew("") first, fixes the issue?
And is @Zackster saying that is correct, albeit unfortunate, behavior because of backward compat?
The file above is base.cfc, which Query.cfc extends. Unless @mgatto 's CFQuery is in a CFC named base.cfc, I think that simple represents the variables inside Lucee’s internal Query.cfc which is used behind the scenes. It’s a transient and it hurts nothing if it uses its internal variables scope. I think there’s some confusion between variables created in Michael’s CFC and variables created inside Lucee’s internal query CFC’s.
Actually, we do have an actual file called base.cfc. Is this an “uh oh” moment for me?
Can you show the full code of the query in that CFC? Also, do a simple and quick test.
<cfquery name="local.foo" >
...
</cfquery>
<cfdump var="#variables#">
<cfdump var="#local#">
<cfabort>
And see where the query lives.
The original query, whose pattern many of ours currently follow:
<cfset var AllAttributesQuery = '' />
<cfquery name="AllAttributesQuery" datasource="#variables.datasource#" timeout="#CreateTimeSpan(0,0,timeout,0)#">
....
</cfquery>
In a test.cfm, the query is in the local scope:
and in the variables scope was this (seems like qry result meta stuff?):
I performed the same test with a fresh CFC and got the same results.
I think that may be working as designed. i.e. your actual query result of local scoped, but the metadata about the query still went into variables.cfquery. If you’re not using that, you probably don’t care. If you want to change the metadata as well, use the results attribute of cfquery.
I’m not concerned about the meta ending up in the variables scope. I’m trying to decide if that’s a false positive logged in Lucee’s debug log for var scoping problems. Basically, can I tell my organization, “yup, we’ve cleared out var scoping errors in this codebase” while we still see these cfquery found in variables log entries?
Well, it’s not a “false positive” in the sense that it really is a variable being put in the variables scope. But it’s variable that it sounds like you’re not using so there’s really on harm to it. If you want to get those lines out of your report, then use the results attribute to cfquery put the meta in a local var.