DEPRECATION WARNING

This documentation is not using the current rendering mechanism and is probably outdated. The extension maintainer should switch to the new system. Details on how to use the rendering mechanism can be found here.

Caching

As explained above, Data Query performs some rather intensive calculations. In order to avoid repeating them needlessly, it implements it own caching mechanism. Cache is written to the tx\_dataquery\_cache table. Entries are keyed to the page they are related to (page\_id field) and to the Data Query record being executed (query\_id field). Furthermore every entry in this table is identified by a unique hash constructed from the following components:

  • the current filter applied to the query, if any
  • the list of primary keys provided by the secondary provider, if any
  • additional, optional parameters (this feature is currently not used)
  • the current FE language ($GLOBALS['TSFE']->sys_language_content)
  • the current FE user groups, if any

The last two parameters ensure that the cache is stored correctly with respect to language and FE user rights, since all this is handled automatically by Data Query (as described above). The Data Structure gets stored into cache as a serialized array. Storage will be aborted if the size of the resulting string exceeds the cache limit, as defined in the extension’s configuration (see “Installation” above). This mechanism ensures that the cache table does not grow out of control, as this could not only slow the system, but even crash the database server.

Every time Data Query needs to execute a query, it will first look if it has an existing, up to date Data Structure in the cache. If it does, it will get the cached data and unserialize it. Otherwise, it will calculate a new Data Structure.

The duration of the cache is defined for each query as shown in the User Manual. The default value is 86400 seconds (= 1 day). Setting a value of “0” will disable caching for the query (see below).

When to avoid caching

The basic reasons for using the Data Query cache is to avoid calculating the whole Data Structure again if it has already been done. This can be – for example – because a given search pattern has recently been already used. Quite typically it is also used when paginating through results. As Data Query handles the limits itself (as explained above) it will re-use the same Data Structure when paginating through records (the limit is not part of the cache key hash; all records are stored in the cache).

There are however circumstances when this caching mechanism is useless. When using a cached Display Controller (pi1), the resulting content will be put into the TYPO3 cache along with the rest of the page. When that page is called up again, it is served from the TYPO3 cache. Data Query is not called at all, its cache is not needed. In such a case, the cache duration of relevant queries should be set to “0” in order to avoid bloating the Data Query cache table with useless entries.

Cleaning up the cache

Whenever a query is modified the cache should be cleared, to ensure that old data will not be served anymore. Data Query hooks into TYPO3’s cache clearing mechanism to simplify this task:

  • when executing the “Clear all caches” command, the tx\_dataquery\_cache table will be emptied
  • when executing the “Clear page cache” command, all tx\_dataquery\_cache entries related to that page will be deleted

However expired cache entries are never deleted, as TYPO3 does not provide an automatic way to do this. Instead you should seriously consider using an extension such as “cachecleaner” that makes it easy delete expired records from any database table on a regular basis.