Difference between revisions of "Cache API"

Revision as of 02:06, 1 July 2009

This is a development page for the Cache API that we are currently implementing. Talk to EmuWikiAdmin- for more information.

Ok the dummy was implemented here : http://www.emuwiki.com/testinstall/extensions/CacheAPI.txt EmuWikiAdmin- 01:04, 28 June 2009 (UTC)

I also have a somewhat working version here : http://www.emuwiki.com/testinstall/extensions/CacheAPI_current.txt

For now, all it takes to make it work is to rename to php, include in Local Settings, and execute the following SQL command :

 CREATE TABLE IF NOT EXISTS `cacheapi` (
`page_ids` INT(10) NOT NULL ,
`dependencies` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`first` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`type` INT(10) NOT NULL ,
INDEX ( `page_ids` , `dependencies`(40) , `first`(40) , `type` )
) ENGINE = MYISAM 

This version implements the 3 types of dependencies (category, template, linksto), but no time dependency yet.

For now, only saving (editing, creating) an article will outdate the cache, not doing other things such as deleting or moving articles (to come).

Updated June 27th 21:00

EmuWikiAdmin- 01:04, 28 June 2009 (UTC)

TODO :

• Implement other types of dependencies (Namespace, linksfrom, etc...)
• Implement the NOTs (notcategory, notlinksto, etc...)
• Make a better system for deleation of dependencies (right now, the only thing you can do is delete ALL dependencies related to a page at once)
• Implement cache outdating when special events other than edit/create are performed (deletion, rename, etc...)
• If you need anything else, add it here.

First Feedback

Hello Jean-Francois,

I decided to call your API immediately before executing my own SQL, that is near line 2418 in DPLMain.php. I used the following code to call your interface:

		// update dependencies to CacheAPI whenever the page containing the DPL query is edited
		
		if ($wgRequest->getVal('action','view')=='submit') {
			CacheAPI::remDependencies ( $wgArticle->getID()); 
			foreach ($aIncludeCategories as $categoryGroup) {
				foreach ($categoryGroup as $category) {
					$title = Title::makeTitle(14, $category);
					$catID = $title->getArticleID();
					CacheAPI::addDependencies ( $wgArticle->getID(), 1, $catID, ''); 
					// die ("adding to DEPENDENCIES: ".$title->getArticleID());
				}
			}
		}

• you must add a "global $wgArticle;" somwehere above this code.
• Is it correct that you expect the pageID of the page containing the DPL statement as the first argument?
• Would it make sense to add a second index to your table to spped up search when dependant articles are changed?
• What is the & separator good for? I have groups of OR-wired cats. All groups are AND-wired....
• I would like to use symbolic constants instead of pure numbers for the types (1,2,3)
• I had to delete the final php delimiter at the end of your source code because there seems to be some invisible UTF code after it.
• I created a small article containing the following query:

         {{#time:Y-m-d h:i:s}}
         {{#dpl:
         | category = Test¦Fictitious country
         }}

• I used the following parameter in the LocalSettings.php (because this would be a typical configuration for a huge wiki I guess):

 ExtDynamicPageList::$respectParserCache = true;

• Instead of doing this I could have written in the DPL query

| allowcachedresults=true

• The #time statement is very useful - so you can see that the time does NOT change if you reload the query page multiple times.
• After editing the query page I saw two entries in the new table, correctly pointing to the two categories (Test , Fictitious country)
• Multiple reloading of the query page showed the same date/time each time (which is correct because the ParserCache is enabled)
• Then I modified Nigunda Test which is one of the articles occuring in the query result in a different browser window.
• I expected the cache now to be invalidated. So when I pressed F5 on the window with the query page I should have gotten a new time stamp - but this did not happen.

• I have no idea how the ParserCache works but the whole idea is:
  1. use the ParserCache - even for pages containing DPL queries (by default DPL switches the cache off so onbe must pay attention here)
  2. change a page contained in the result (regardless what kind of change, I assume at the moment)
  3. refresh the DPL page
  4. ... and watch that the DPL page is no longer delivered from cache but recalculated.

I think it is best if you set up a similar configuration (article names and cat names may differ) and then try to make the simple example with one or two categories work on your pc. If you have to change the lines in DPLMain.php which I used to call your API: go ahead and tell me what you have done.

Note: I observed that your table changes also if a dependant page is being edited. In my case another entry was added for 'Nigunda Test'. I do not understand why this is necessary and I am afraid it will slow down regular editing.

Happy testing!

Gero

I'll take the time to review each of your remarks, thanks a lot for testing. However I think there's an error in the way you use addDependencies, and i'd like you to check this. The third argument seems to be a problem, I was expecting a string containing the conditional statement with '&' as separators. For example, if you want page 605 (which contain the DPL statement) to be dependant on the edition of articles that are in categories AA & BB, I would expect a call like this :

CacheAPI::addDependencies ( $wgArticle->getID(), 1, 'AA&BB', );

or if it's just dependent on 1 category like AA :

CacheAPI::addDependencies ( $wgArticle->getID(), 1, 'AA', );

That's probably why the cache did not outdate correctly in your test. Can you test that again just to see if that's the problem ? I'll have time to work on the other remarks tommorrow and I'll keep you updated. EmuWikiAdmin- 00:06, 1 July 2009 (UTC)