Sorry that I wasn't able to respond earlier but we made some effort to
make the integration bit more sound and add a functionality that
enables SMWQueryCache to invalidate query cache objects based on
individual objects that are contained within each query. For a more
exhaustive explanation see .
## General changes
We leave the class SMWQuery unharmed and instead having an extended
class SMWQueryExtended the implements the getHash() functionality.
All functionality has been transferred into its own class SMWQueryCache.
SMWAskPage and SMWQueryProcessor now use:
$querycache = new SMWQueryCache;
$res = $querycache->getQueryCacheResult( $query, $params )
We introduce a new method (createAssociatedQueryCache) with which
queries are able to track individual objects that are contained within
each query. Should one of those objects change/or become obsolete
linked queries are invalidated immediately. The so called associated
cache objects are kept as a separate cache entity (see more )
allowing to avoid additional database select/write within the
SMWQueryCache class (which was the purpose after all).
For cache invalidation we rely on three hooks
$wgHooks['smwDeleteSemanticData'] whereby the only new hook we need
is $wgHooks['smwChangeTitle'] because when a page gets moved neither
of the above hooks have been activated.
In general their are only three minor changes to the SMW core that
would be necessary to allow to use all functionality provided by the
## Respond to earlier emails
I was ware of it but since our users started to use Special:Ask
>> Are you aware of Nicschayns Summer of Code project ?
queries more often during the Special:Search session we have seen an
increased need to bundle those identical queries.
The general idea of this email was to push some ideas forward before
>> Better coordinate to avoid both doing the same work in parallel :)
everything is set in stone.
Actually we can't sort since the result is stored the way printout
>> Since stuff here is not sorted, you can have the same query with different hashes
needs the nested objects meaning when the same query is executed but
"hypothetical" columns are switched getQueryResult would return with a
different order in $res therefore a different sorting of columns have
to have a different hash key in order for the PrinterResult to match
$res and the printout statements.
> I'm in favor of using wfGetCache( CACHE_ANYTHING ).
>> integration could be better
Everything is transferred into the SMWQuery class
Disabling query cache completely by setting set $smwgQueryCache =
>> you change something that you want to see reflected in your query right away
false or for a specific query to set $params['cache'] to false which
then works on a per query basis.
See also 
Using associated cache objects, see above explanation and 
>> no way to invalidate the cache
>> Globals are evil
We moved away from wgMemc and instead use wfGetCache( ... )
>> replace the expiry time ... configurable value
Using $smwgQueryCacheExpiry and see also