Lazy Queries Deprecated?

While working on a creative use of Application query listeners (attaching a unique execution id and tracking every query), I noticed in the cfquery documentation that the lazy attribute of cfquery is apparently deprecated, which I was unaware of.

We use and love that feature of queries and it makes a massive difference on large report exports, etc. I searched here and found no references to why, so I figured I would ask, hoping it is perhaps a mistake or there is some simple replacement I should be aware of.

Thanks in advance for any insight!

docs updated

The new recommended BIF is queryLazy, the old way is still there but deprecated

Attribute docs cross linked and updated

2 Likes

Thanks @Zackster as always! Glad to here the feature is still around, though queries and output are two of those things that are unfortunately far better expressed in tag syntax than script. With a function listener its much more awkward keeping context and we’re forcing the query and its output to happen at the same time instead, breaking common patterns like MVC and creating situations where big-ass strings of output would need to be held in memory unless the query is placed inline in view code.

I also liked that we could control the looping, grouping, and closing of the result set because we use it for some very large file exports that we stream out over http. I just feel there is often a good reason tags are supported. Output, queries, and mail (basically anything templating related) are the most common examples.

Just my two cents, but I understand the protectionist nature of the function.

Thanks for the detailed feedback

Can you elaborate on the lack of context, you mean the scopes the listener UDF runs in?

Yes…typically where we’ll see the use of something like a lazy query is building a large report or pdf file. We try to stream that output as much as possible, so creating the query and then streaming the result set as its being output is helpful. The trick with this is not all the output can often times be described in the context of the listener here, such as variables that might change its format or how records are grouped, etc.

Apologies for the slow responses!