r100933 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:< r100932‎ | r100933 | r100934 >
Date:01:44, 27 October 2011
Author:aaron
Status:ok (Comments)
Tags:
Comment:
Quick and ugly fix to stop installs with CACHE_DB from immediately failing with DB errors. Something is wonked with the order of temp table creation.
Modified paths:
  • /trunk/phase3/tests/parser/parserTest.inc (modified) (history)

Diff [purge]

Index: trunk/phase3/tests/parser/parserTest.inc
——@@ -136,7 +136,8 @@
137137 $wgUser, $wgLang, $wgOut, $wgRequest, $wgStyleDirectory, $wgEnableParserCache,
138138 $wgNamespaceAliases, $wgNamespaceProtection, $wgLocalFileRepo,
139139 $parserMemc, $wgThumbnailScriptPath, $wgScriptPath,
140 - $wgArticlePath, $wgStyleSheetPath, $wgScript, $wgStylePath, $wgExtensionAssetsPath;
 140+ $wgArticlePath, $wgStyleSheetPath, $wgScript, $wgStylePath, $wgExtensionAssetsPath,
 141+ $wgMainCacheType, $wgMessageCacheType, $wgParserCacheType;
141142
142143 $wgScript = '/index.php';
143144 $wgScriptPath = '/';
——@@ -158,10 +159,20 @@
159160 $wgNamespaceAliases['Image'] = NS_FILE;
160161 $wgNamespaceAliases['Image_talk'] = NS_FILE_TALK;
161162
 163+ // XXX: tests won't run without this (for CACHE_DB)
 164+ if ( $wgMainCacheType === CACHE_DB ) {
 165+ $wgMainCacheType = CACHE_NONE;
 166+ }
 167+ if ( $wgMessageCacheType === CACHE_DB ) {
 168+ $wgMessageCacheType = CACHE_NONE;
 169+ }
 170+ if ( $wgParserCacheType === CACHE_DB ) {
 171+ $wgParserCacheType = CACHE_NONE;
 172+ }
162173
163174 $wgEnableParserCache = false;
164175 DeferredUpdates::clearPendingUpdates();
165 - $wgMemc = wfGetMainCache();
 176+ $wgMemc = wfGetMainCache(); // checks $wgMainCacheType
166177 $messageMemc = wfGetMessageCacheStorage();
167178 $parserMemc = wfGetParserCacheStorage();
168179

Comments

#Comment by Hashar (talk | contribs)   16:38, 12 December 2011

Aaron, I have set wgMainCacheType to CACHE_DB and removed the above code and had no issue under SQLite.

How can we reproduce the issue? Do you still reproduce it in recent trunk ? :)

#Comment by 😂 (talk | contribs)   19:20, 14 December 2011

Shouldn't we just unconditionally disable all caches in testing?

#Comment by Hashar (talk | contribs)   14:57, 22 December 2011

MediaWiki is sluggish without cache. So I would prefer keeping a basic level of caching, specially APC which is so easy to enable and fast.

Or we could unconditionally setup a per process hash cache such as HashBagOStuff ? :D

#Comment by 😂 (talk | contribs)   15:20, 22 December 2011

The shared memory caches (like APC) are useless on the command line, see bug 28752 and related discussions.

#Comment by Nikerabbit (talk | contribs)   15:23, 22 December 2011

It's not totally useless, APC can be enabled for CLI mode too, and as far as I know it uses the same cache as for web requests so it should be fine. However this is not the default configuration.

#Comment by Aaron Schulz (talk | contribs)   02:53, 23 December 2011

HashBagOStuff is reasonable.

#Comment by Hashar (talk | contribs)   09:37, 23 December 2011

The only drawback I can think about with HashBagOStuff, is the lack of memory limiter. Though, if it proves to be an issue later, we can just fix our code.

#Comment by Hashar (talk | contribs)   11:09, 5 January 2012

I can not reproduce the issue.

I have locally reverted that revision, set up $wgMainCacheType = CACHE_DB; and launched the parser tests. No issue!

From my debug log: 

CACHES: SqlBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]

So I am wondering if this is really needed.

#Comment by Aaron Schulz (talk | contribs)   18:04, 5 January 2012

I definitely had failures before, which is why I did this rev.

Status & tagging log