Cache the processed data

[flolopdel]

We experience slow request in the processed data.

The difference is hudge between the jdbc time spent and the total time spent of the request and this time come from the 2 loop which is done in the processed data for api.

To prevent this time I add a check which check if the data come from the querycache or from the query database.

If the data come from the query database, the processed is done in the old way and it update a cache key with this info
If the data come from the query cache, I also get the processed data from the cahe, adding more speed to the request.

I hope this help and can be add soon to the extension. If is there anything I can do, let me know

[DominicWatson]

Thanks @flolopdel - have added to our current sprint for review (may be a a little while with public holidays for our office rn)

[DominicWatson]

This feels dangerous / misplaced. This interception point could easily be fired off 1000's of times in any given request (i.e. some bad uncached admin request with lots of little queries). From my understanding, you want to use a 'processed' cache of the select data results, only when the select data result hasn't changed.

I think a more accurate / clean approach here would be:

1. Create a dedicated API result cache
2. Do your selectData as normal
3. Generate a cache key that is API Endpoint + a hash of the db query result

Then just use your dedicated API cache with this cache key. If the data changes in the DB, that cache entry will no longer get looked up.

Does that make sense? Here is an example of an extension registering its own cachebox cache using afterConfigurationLoad coldbox interception point: https://github.com/pixl8/preside-ext-s3-storage-provider/blob/stable/interceptors/S3StorageProviderInterceptors.cfc

[flolopdel]

Hi @DominicWatson !

I understand you.

The answer to the question 2 Do your selectData as normal Is the reason I add the interceptor onCreateSelectDataCacheKey To check if the data from the selectData has been cached or not.

• If it was cached then get the cache specific for api result
• If not, processed and save cached

What do you propose to do this without use the intercelpor onCreateSelectDataCacheKey ?

It is true onCreateSelectDataCacheKey is fired a lot of times but it is also true I did not do any important action there more than set true or false some RequestContext

[DominicWatson]

To check if the data from the selectData has been cached or not.

This does not essentially matter. All that matters is that you have a version in cache that matches the result of the query. If the query is cached and the API result is cached then super-great. If the query is not cached but the result has not changed and we still have an API result cache, then we can still use this API result cache.

[DominicWatson]

@flolopdel Have added some review feedback above. Let me know what you think and/or if you'd like any help with this.