Page MenuHomePhabricator

Use of temporary tables in parser tests broken by r40209
Closed, ResolvedPublic

Description

Author: ayg

Description:
Since r40209, I get this when running parserTests:

$ php maintenance/parserTests.php
This is MediaWiki version 1.14alpha.

Reading tests from "maintenance/parserTests.txt"...
A database query syntax error has occurred.
The last attempted database query was:
"SELECT value,exptime FROM parsertest_objectcache WHERE keyname='wikidb-parsertest_:messages:en'"
from within function "MediaWikiBagOStuff::_doquery".
MySQL returned error "1146: Table 'wikidb.parsertest_objectcache' doesn't exist (localhost)"

Needless to say, I've run update.php. Backing out the commit causes it to work fine.


Version: 1.14.x
Severity: minor
OS: Linux
Platform: PC

Details

Reference
bz15892

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 10:19 PM
bzimport added a project: MediaWiki-General.
bzimport set Reference to bz15892.
bzimport created this task.Oct 8 2008, 2:42 PM

ayg wrote:

Still broken.

The problem is that r40209 doesn't play nicely with the use of temporary tables in parserTests.inc. Disabled the latter in r44003 as a temporary workaround, so that us poor folks with only one database can run parser tests again. Should be fixed properly, though.

*** Bug 16374 has been marked as a duplicate of this bug. ***

Prepending "Use of temporary tables in" to bug summary to reflect current status.

Seems to have been fixed in the meantime. Reenabled in r67113.

Not fixed properly. Anything that triggers CACHE_DB explicitly fails.

Can you provide an example ?

brion added a comment.Apr 6 2011, 9:42 PM

This still happens intermittently for me, though I'm uncertain the immediate cause.

r82582 and the MediaWikiTestCase.php change of r82867 (updated by r83418) should have fixed it.
Did they reappear only recently? Maybe some of the recent initialization changes broke them again.

brion added a comment.Apr 8 2011, 9:10 PM

Still fails on trunk as of r85689...

Platonides, are there now two different ways of running the parser tests? It kinda looks like some of the MediaWikiTestCase and NewParserTest.php stuff duplicates code in parserTest.inc, and I've got a sneaking suspicion that this is in the middle of a transition or something.

ParserTest::setupDatabase() in parserTest.inc has this comment:

  1. SqlBagOStuff broke when using temporary tables on r40209 (bug 15892).
  2. It seems to have been fixed since (r55079?).
  3. If it fails, $wgCaches[CACHE_DB] = new HashBagOStuff(); should work around it.

If I copy in this (newer) line from MediaWikiTestCase in that position:

ObjectCache::$instances[CACHE_DB] = new HashBagOStuff;

it seems to help.

Yes, you can run the parser tests in two ways:

  • The good old parserTests.php
  • As part of phpunit tests. (make parser to run just parser tests in phpunit). This way each test is run isolated from the other, but is also much slower.

And yes, the phpunit code was initially "forked" from parserTest.inc (but don't think parserTest.inc hasn't also evolved).

I'm not aware of a current migrating effort.

You should commit it. r82867/r83418 only affects NewParserTest since it's the one extending MediaWikiTestCase (we would benefit here from a multibple heritance if php allowed that).

The $wgCache issue was a bit complicated, it's probably the same issue. I don't know if a EmptyBagOStuff should be preferable to a HashBagOStuff.

brion added a comment.Apr 8 2011, 11:07 PM

Spiff... committing the HashBagOStuff for now (empty probably fine too) as r85702.

We'll have to go through and re-merge the two alternate trigger methods at some point probably. Whee! :D