Just so you know: you could submit a change on Gerrit in case some of your implementation could be merged with SMW
permanently and used by everyone else. The code can be reviewed there very well as compared to github.

I am still working on the SMW store interface and will look into caching queries later. If your implementation could be used
by SMW we can avoid doing the same tasks separately.

On Thu, Jun 7, 2012 at 2:42 AM, James HK <jamesin.hongkong.1@gmail.com> wrote:

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 [1].

## 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 [1])
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
class SMWQueryCache.

* SMWAskPage
* SMWQueryProcessor
* $wgHooks['smwChangeTitle']

## Respond to earlier emails

>> Are you aware of Nicschayns Summer of Code project [0]?
I was ware of it but since our users started to use Special:Ask
queries more often during the Special:Search session we have seen an
increased need to bundle those identical queries.

>> Better coordinate to avoid both doing the same work in parallel :)
The general idea of this email was to push some ideas forward before
everything is set in stone.

>> Since stuff here is not sorted, you can have the same query with different hashes
Actually we can't sort since the result is stored the way printout
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

>> you change something that you want to see reflected in your query right away
Disabling query cache completely by setting set $smwgQueryCache =
false or for a specific query to set $params['cache'] to false which
then works on a per query basis.
See also [2]

>> no way to invalidate the cache
Using associated cache objects, see above explanation and [3]

>> Globals are evil
We moved away from wgMemc and instead use wfGetCache( ... )

>> replace the expiry time ... configurable value
Using $smwgQueryCacheExpiry and see also [4]

[1] https://github.com/mwjames/smw-querycache

[2] https://github.com/mwjames/smw-querycache#integration-with-srf

[3] https://github.com/mwjames/smw-querycache#query-invalidation

[4] https://github.com/mwjames/smw-querycache#query-cache-parameters-localsettingsphp




Nischay Nahata