I just ran into an issue with a cached query where a user has taken action and I know that the cache is now invalid. I've located cfobjectcache ( https://docs.lucee.org/reference/tags/objectcache.html ) but it doesn't define the object used as a filter and https://docs.lucee.org/guides/Various/TIPS/TIPS-tricks.html tells me that I should just provide it a string which would then be... what, tested against the text SQL for all objects in the query cache? Seems like it might be overly broad. Is best practice really just a cache clear on the same string I fed into a cfqueryparam tag? Side note: To be honest, my real preference would be a boolean I could pass into cfquery that would force a cache miss and recaching, so that I could leave it false and then set it to true if a user just submitted a thing. Would a feature request for it seem productive?

as the query cache is keyed off a hash of the sql, datasource, params etc, so just pass in a cachebusting param

That won't help though.

SELECT fields
FROM tables
WHERE userKey = 47

Then there's an update, and then in that same request we could...

SELECT fields
FROM tables
WHERE userKey = 47
/* cachebuster */

But the next request, the next page load, won't have the same cachebuster. It'll reprise the first query and that's still wrong.

you could just mange the caching yourself in cfml, with all your own business rules

Yeah, okay, thanks for the response.

🙂

Opened https://luceeserver.atlassian.net/browse/LDEV-4235 .

Couldn't you also shorten the cache time so it reruns if you know the data is old?

if the users have sessions, you could store something like

session.cacheToken = gettickcount();

and have it be passed into the relevant queries so it's appended as

AND #arguments.cacheToken# = #arguments.cacheToken#

. that way it won't affect the query and you can force it to recache by simply setting a new gettickcount() to the session. personally i prefer leveraging ehCache or the like over the built in cachedWithin attributes, more control

That would work, websolete, you've made a persistent token that can be changed to force a cache miss.