cfargument type of query

I have been working on a component for the past few days with a method that optionally takes in a query as an argument. Initially, I was having some problems in the method because my isQuery() function was not working. Well, here is what I was doing:

<cffunction name="generateElement" access="public" returntype="string" output="false">
<cfargument name="qUserData" type="any" required="false" default="">

<cfif isQuery("arguments.qUserData")>
<!--- do something with the query data --->
</cfif>

</cffunction>

See where the problem is? When I put the arguments.qUserData in double quotes, the function evaluated it out to a string. So, I removed the double quotes and things were better.

I then chatted with a co-worker (and a CF guy who has tons of experience). He mentioned that I could default the qUserData argument as a queryNew("nodata") and just skip the if in the method and loop over the query, because if the query is not there, I wouldn't need to do the "something" in that method, but would do something else entirely. So, the new method looks like this:

<cffunction name="generateElement" access="public" returntype="string" output="false">
<cfargument name="qUserData" type="query" required="false" default="#queryNew("nodata")#">

<cfloop query="arguments.qUserData">
<!--- do something with the query data if we have it --->
</cfloop>

<!--- other code here --->
</cffunction>

I like this way better because I do use typing of my arguments (as does most of my team) when we build or products and APIs. Notice that no IF was required which can save on processing, and the loop will not execute if the recordset is empty. There are tons of different ways to do this, but this is just something to think about.

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
Rick O's Gravatar "Notice that no IF was required which can save on processing"

If you believe that creating a new query object is less expensive than a single if statement, I know a Nigerian Prince you should meet.
# Posted By Rick O | 11/11/08 12:04 PM
johann's Gravatar @Rick O

I can see your point. What I could have done, and might still do, is create a variabled scoped (attribute) of the component, and have that as the default, so then I only have to create it once, when the bean is put in to application scope in ColdSpring. This component and many of the methods that do this same check, will be called probably up near 1000 times an hour, so yeah, great idea to just create it once! Thanks Rick!
# Posted By johann | 11/11/08 1:14 PM
Ben Nadel's Gravatar @Rick,

Always with the astute suggestion. Always on the ball.
# Posted By Ben Nadel | 11/11/08 3:48 PM
ike's Gravatar @Rick - that would be what you do after you discover that you have a performance issue, not before.
# Posted By ike | 11/11/08 7:39 PM
Chris's Gravatar @Ike - I disagree... you have to think of possible performance issues before they happen. Fixing them afterwards is much more expensive than avoiding them.
# Posted By Chris | 11/12/08 7:55 AM
ike's Gravatar @Chris - to an extent, that's true... but not to this extent... Should you query the database for every column (including a CLOB) to get a single numeric value, no... that's a *HUGE* amount of gratuitous overhead for a very small result... but worrying about performance at this level pre-emptively is splitting hairs. You're talking about the difference between two operations that, neither of which likely take even a single millisecond to perform. The long term benefit of splitting hairs over that is negligible, even assuming that it's not actually counter-productive, which it may be.
# Posted By ike | 11/12/08 11:21 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.7.002.