Difference between revisions of "Talk:Cache API"

Revision as of 07:02, 1 July 2009

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.

Ok tried it. You version didn't work because you were using numbers (page ids) for categories, I was using text. See discussion below.

• Is it correct that you expect the pageID of the page containing the DPL statement as the first argument?

Yes.

• Would it make sense to add a second index to your table to spped up search when dependant articles are changed?

Yes, all columns will be indexed. The SQL query makes them all indexes. And since we're shifting to category IDs (see below), we will be able to index the column in which we search.

• What is the & separator good for? I have groups of OR-wired cats. All groups are AND-wired....

Aren't we forced to store the AND relations between the categories ? For example, When a DPL invocation looks for articles in categories AA & BB, we don't want to outdate the cache of the DPL page's invocation if an article of only category AA is touched. We want it to be purged only if an article of AA _AND_ BB is touched. The way you used addDependencies should be used only for the OR relation, that is to add separate entries for separate categories. When the AND relation is present (specified by user or implicit), you should pass an array of category ids as a 3rd argument (see below).

• I would like to use symbolic constants instead of pure numbers for the types (1,2,3)

Ok. In the next version, we will use CACHETYPE_CATEGORY CACHETYPE_TEMPLATE and CACHETYPE_LINKSTO

• 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.

No idea how it happened! Probably my text editor/uploader.

• 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)

The only reason it worked for you is that all your categories are true pages that are in fact created. This is not the case for all wikis and probably not for Wikipedia. We have to find another way to work with categories than the makeTitle strategy using page numbers to identify them. See discussion below.

• 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 will send you a modified version of both my extension and your DPLMain.php that work.

• 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.

This is weird. Was there a DPL invocation in Nigunda Test ? I've never seen this behavior. We'll look at this when you try the corrected versions.

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', ); - outdated, the 3rd argument will now be an array of category numbers

Actually the way you did it might just be better, I might switch to using page numbers instead of the names of the categories... I don't know what happens with mediawiki when category articles are deleted and recreated. I'll have to look at this, we don't want category numbers stored in the cacheapi to mean nothing whenever a category is changed, or deleted and recreated after that. For this reason I used the category names. I'd still like to see if it works for your test if you call addDependencies as described above. EmuWikiAdmin- 02:14, 1 July 2009 (UTC) - outdated, now using cat IDs

I just tested it. Did you know that Title::makeTitle(14, $category) does not work if the category page has not been created ? This is due to the fact that a category can exist without the category page being made. That's a big problem because lots of categories are likely to exist but not all of them have a category page already made. Maybe we should go back to storing the dependencies in the form of strings like AA&BB, or do you see another possibility ? Maybe we should work with cat_ids instead of page_ids. Look at the Category table, it might be easier to index and it would speed up the search, and it wouldnt have the same problems that makeTitle has. EmuWikiAdmin- 04:43, 1 July 2009 (UTC)

Here's a working version of the Cache API : http://www.emuwiki.com/testinstall/extensions/CacheAPI_current.txt . The difference with this version is that CacheAPI::addDependencies now takes an array of category IDs as 3rd argument. Here's what you will need to use in DPLMain.php :

		// update dependencies to CacheAPI whenever the page containing the DPL query is edited
		
		if ($wgRequest->getVal('action','view')=='submit') {
			CacheAPI::remDependencies ( $wgArticle->getID()); 
			$categorylist = array();
			foreach ($aIncludeCategories as $categorygroup) {
				foreach ($categorygroup as $category) {
					$catobj = Category::newFromName( $category );
					array_push ( $categorylist , $catobj->getID() );
				}
			}
			CacheAPI::addDependencies ( $wgArticle->getID(), 1, $categorylist, ''); 
		}

I'm not sure I totally understood what's the structure of $aIncludeCategories so I just included everything as if it would be all AND-related. Maybe I'm wrong

EmuWikiAdmin- 04:43, 1 July 2009 (UTC)

You can try for yourself, it works if you test it the way you tested (don't try the linksto and template, but the category works). Right now I need no more input from you I'll go on and improve the system, since I know where you call the API in DPL I might also change DPLMain.php itself if I have problems. I'll be back with more functionalities and a better manual to document all those functionalities. Thanks for your test! EmuWikiAdmin- 04:53, 1 July 2009 (UTC)