Hi, 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['SMWStore::updateDataBefore'][], $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 ). Done >> 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 Cheers mwjames ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
