Difference between revisions of "Cache API"
Line 42: | Line 42: | ||
I decided to call your API immediately before executing my own SQL, that is near line 2418 in DPLMain.php. | 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: | ||
− | + | // add dependencies to CacheAPI | |
− | + | foreach ($aIncludeCategories as $categoryGroup) { | |
− | + | foreach ($categoryGroup as $category) { | |
− | + | $title = Title::makeTitle(14, $category); | |
− | + | $catID = $title->getArticleID(); | |
− | + | CacheAPI::addDependencies ( $wgArticle->getID(), 1, $catID, ''); | |
− | + | } | |
− | + | } | |
− | |||
+ | * you must add a "global $wgArticle;" somwehere above this code. | ||
* Is it correct tha you expect the pageID of the page containing the DPL statement as the first argument? | * Is it correct tha you expect the pageID of the page containing the DPL statement as the first argument? | ||
− | * I noticed that multiple edits of my article lead to multiple redundant entries in your cache table. I think you | + | * I noticed that multiple edits of my article lead to multiple redundant entries in your cache table. I think you must clear old entries for the query page before you add new ones. |
− | * What happens if the DPL statement changes? Let us say if | + | * To increase perfromance it is advisable to define an index for the table (or two). |
− | * I would like to | + | * What happens if the DPL statement changes? Let us say if a query first used cat A but now it uses cat B as a search criterion. Will you delete the old inmformation in your table? |
− | * I had to delete the final php delimiter because there seems to be some invisible UTF code after it. | + | * 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: | * I created a small article containing the following query: | ||
− | + | {{#time:Y-m-d h:i:s}} | |
− | + | {{#dpl: | |
− | + | | category = Fictitious country | |
− | + | }} | |
− | * I used the following parameter in the LocalSettings.php: | + | * 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; | ExtDynamicPageList::$respectParserCache = true; | ||
− | * Instead of doing this I could have | + | * Instead of doing this I could have written in the DPL query |
| allowcachedresults=true | | allowcachedresults=true | ||
− | * I saved the query and then modified [[Nigunda Test]] which is one of the articles in the query result in a different browser window. | + | * The #time statement is very useful - so you can see that the time does NOT change if you reload the query page multiple times. |
− | * I expected the cache to be invalidated. So when I pressed F5 on the | + | * I saved the query page and then 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. | ||
* Instead there was much resource consumption on the PC before the page was shown again. | * Instead there was much resource consumption on the PC before the page was shown again. | ||
− | * Afterwards the table contained lots of entries (ca. 40) | + | * Afterwards the cacheapi table contained lots of entries (ca. 40) |
− | 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 category work on your pc. If you have to change the | + | 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 category 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. |
Happy testing! | Happy testing! | ||
Gero | Gero |
Revision as of 23:39, 29 June 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:
// add dependencies to CacheAPI foreach ($aIncludeCategories as $categoryGroup) { foreach ($categoryGroup as $category) { $title = Title::makeTitle(14, $category); $catID = $title->getArticleID(); CacheAPI::addDependencies ( $wgArticle->getID(), 1, $catID, ); } }
- you must add a "global $wgArticle;" somwehere above this code.
- Is it correct tha you expect the pageID of the page containing the DPL statement as the first argument?
- I noticed that multiple edits of my article lead to multiple redundant entries in your cache table. I think you must clear old entries for the query page before you add new ones.
- To increase perfromance it is advisable to define an index for the table (or two).
- What happens if the DPL statement changes? Let us say if a query first used cat A but now it uses cat B as a search criterion. Will you delete the old inmformation in your table?
- 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:
2024-11-24 09:40:03
- 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.
- I saved the query page and then 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.
- Instead there was much resource consumption on the PC before the page was shown again.
- Afterwards the cacheapi table contained lots of entries (ca. 40)
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 category 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.
Happy testing!
Gero