@Brad Wood ACF has a complete independent implementation for query cache. with introduction of caches in Lucee (Railo)(cacePut,cacheGet,..) we decided to use this caches also for cfquery. So you can simply define a EHCache for "query" and limit the amount of elements in memory and you have the same behaviour.

@Carl Von Stetten fair point

@Michael Offner The reason the Adobe behavior is not dangerous on Adobe is because there is an admin setting called "Number of cached queries" which puts a max on the number of queries that will be cached and applies a FIFO eviction policy to clear old ones.

Lucee does not have this setting so far as I know. Perhaps the real fix is for Lucee to also implement the same max query cache that Adobe has? Or at least put in some sort of cap so the query cache won't grow unbounded. Then we can support the same query caching as Adobe without it being dangerous.

Michael,

I respectfully disagree with deviating from the precedent, no matter how BAD you think that precedent is. But I'll yield on that for the moment.

However, I just did some testing on ACF using `cachedWithin` and `cachedAfter`. ACF does not allow both to be used together. You can only use one or the other. So if a user wrote a `<CFQUERY>` using the implementation you've chosen on Lucee, and then tried to run the same tag on ACF, it would throw an error. I don't think this is really a desired outcome.

I created a discussion on dev.lucee.org here: https://dev.lucee.org/t/cfquery-cachedafter-attribute/4853

-Carl

@Carl Von Stetten agree that can be a friction moving code from ACF to Lucee, but as i pointed out the feature seem not very popular and not fully supporting it, does not do any harm in most cases. With any change i also have to consider the harm i do to people updating their code from an older Lucee version.

In addition my PERSONAL opinion is that the ACF implementation is BAD and should not be followed.

We do not blindly follow ACF in many cases when we disagree on how they do stuff.
In many cases we add options to Lucee, so the user can decide, as i suggested in this case.
So in the end we only discuss what the default behaviour will be, we add the same possibility as ACF has, simply not by default.

But you are right, it is a "Incompatibility" ticket, so the right way to do this would be to reject that ticket and instead open a bug ticket that points out that "cachedAfter" does not work as expected and solve that one.
But that would make things simply more complicated.

I'll start a discussion on dev.lucee.org. However, I still maintain that since this was a Incompatibility ticket, it should have been implemented in a manner that was compatible with the ACF implementation. If this was a greenfield feature being added to Lucee (and didn't already exist in ACF), I'd be all for writing it in a manner that is safest for the end user. But since this was to close an incompatibility gap, this should not be yet another point of friction in moving code from ACF to Lucee.