spunog
01/17/2024, 11:22 AMx = findPerson(searchTerm="John's Stuff");
...
<cffunction name="findPerson">
<cfargument name="searchTerm" type="string" required="yes" hint="John's Stuff" >
<cfquery name="local.mainQ" datasource="somedatasource">
SELECT person.Lastname
FROM person
WHERE 1=1
<cfset local.ownername = TRIM(arguments.searchTerm)><!---results in double apos e.g. John''s Stuff--->
AND person.Lastname LIKE <cfqueryparam value="%#local.ownername#%">
</cfquery>
<cfreturn local.mainQ>
</cffunction>
vs
<cffunction name="findPerson">
<cfargument name="searchTerm" type="string" required="yes" hint="John's Stuff" >
<cfset local.ownername = TRIM(arguments.searchTerm)><!---John's Stuff. As expected--->
<cfquery name="local.mainQ" datasource="somedatasource">
SELECT person.Lastname
FROM person
WHERE 1=1
AND person.Lastname LIKE <cfqueryparam value="%#local.ownername#%">
</cfquery>
<cfreturn local.mainQ>
</cffunction>
We use cfqueryparams everywhere that's possible and for rare cases where it doesn't suit we usually just have a safe list.
Is there a setting to disable the above or is just terrible that in some functions we have a cfset at all within the cfquery tag.adam.euans
01/17/2024, 11:27 AMspunog
01/17/2024, 11:51 AMdfgrumpy
01/17/2024, 2:47 PMspunog
01/17/2024, 3:07 PMdfgrumpy
01/17/2024, 3:24 PMScott Bennett
01/17/2024, 3:33 PMAdam Cameron
<cfquery> works it pretty much forced one's tests to require the DB, which in turn is a barrier to entry for tests.
It's also less than ideal in the "single responsibility principle" department, so reducing the maintainability and understandability of the code.
The method that makes the DB call should do nothing else other than the DB call.
I'd avoid using <cfquery> if I needed to have conditional logic to build the SQL string; I'd separate that out into its own thing, and just use queryExecute to run the SQL .
(that said, I really try to avoid having to write dynamically-constructed SQL strings anyhow. I do know it's unavoidable sometimes)