Coding standards
Security in ResourceSpace
Developer reference
Database
Action functions
Admin functions
Ajax functions
Annotation functions
API functions
Collections functions
Comment functions
Config functions
CSV export functions
Dash functions
Debug functions
Encryption functions
Facial recognition functions
File functions
General functions
Language functions
Log functions
Login functions
Message functions
Migration functions
Node functions
PDF functions
Plugin functions
Render functions
Reporting functions
Request functions
Research functions
Slideshow functions
Theme permission functions
User functions
Video functions
Database functions
Metadata functions
Resource functions
Search functions
Map functions
Job functions
Tab functions
Test functions

Query caching

Overview

The results of selected queries can be cached to disk. This is only really useful where it's likely the same query will be called a very large number of times, for example, queries that are common across several pages and the same for large groups of users. It's probably not worth using this for anything user specific, or specific to a niche / rarely accessed page.

This code was used to bring the number of 'global' queries for a normal page down to 4 from around 30. Additionally on pages such as the Featured Collections page that executed a query for each tile visible, the caching code meant this was only the case when this page was being updated.

Mechanism and security

The disk cache files are in filestore/tmp/querycache which is emptied completely by the cron task (as for most other files in the tmp folder). Also, if a cached result set is older than 30 minutes it's discarded.

The cache files are JSON encoded result sets. The cache files filenames are scrambled using the scramble key, and the filename consists of both the md5 hash of the query and a scramble key seeded version of the same, to prevent hash collisions. The query itself is stored in the JSON and a final check is made to ensure there hasn't been a hash collision, and the cache is discarded in that (astronomically unlikely) event.

Altering code to use the cache

Using the cache for a query is as simple as setting the $cache paramater on ps_query(), ps_value() or ps_array(). It should be set to the name of a cache group, such as "sitetext" or "themeimage" that broadly categorises the functionality. The cache for that area can then be flushed when edits/deletes/updates are made to that area via clear_query_cache(), e.g. to clear the sitetext cache:

clear_query_cache("sitetext");

Potential issues

As mentioned above code that potentially changes items in the cache should call clear_query_cache(). If issues arise where user changes are not taking effect then we need to make sure that function is being called where the functionality in question makes use of disk caching.

Developers directly modifying the database may not see the results of their changes due to the cache. In this case the query cache folder can be manually cleared.