Page MenuHomePhabricator

Table bw_smw_fpt_askdu not found
Closed, ResolvedPublic

Description

Checking table bw_smw_fpt_askdu ...

Table not found, now creating...

but it's never created and I get the "usual"
rakkaus:#mediawiki-i18n- (24 lines skipped) [15-Dec-2013 11:02:32 UTC] PHP Notice: Uncommitted DB writes (transaction from DatabaseBase::query (SMWAdmin::execute)). in /www/translatewiki.net/w/includes/db/Database.php on line 4118

Something went wrong during some update? Why?

In the meanwhile, https://translatewiki.net/wiki/Support/Open_requests or any Special:Ask query we have don't show any update (last additions are from 2013-12-02), purging and data repair don't help.


Version: master
Severity: major
URL: https://translatewiki.net/wiki/Special:SMWAdmin

Details

Reference
bz58502

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:23 AM
bzimport set Reference to bz58502.
Unknown Object (User) added a comment.Dec 15 2013, 4:03 PM

No, have seen it (In reply to comment #0)

Checking table bw_smw_fpt_askdu ...

Table not found, now creating...

Standard message that shows when a table isn't available and needs initialization. Of course if you run update.php without proper authorization it will not be created but since Travis creates and updates tables [0] on each test run (MW 1.19/ MW 1.22), I can't see any issue here.

With the ask query, I suspect that relates to the Composer install issue reported earlier [1] and some unresolved settings issue. Please verify that tw.net, runs the latests beta with [2] available.

[0] https://s3.amazonaws.com/archive.travis-ci.org/jobs/15479065/log.txt

Checking table smw_fpt_askst ...

Table not found, now creating...
... done.

Checking index structures for table smw_fpt_askst ...

... creating new index s_id ...done.
... creating new index o_hash ...done.
... done.

Checking table smw_fpt_askdu ...

Table not found, now creating...
... done.

Checking index structures for table smw_fpt_askdu ...

... creating new index s_id ...done.
... creating new index o_sortkey ...done.
... done.

Checking table smw_fpt_subp ...

Table not found, now creating...
... done.

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=57760#c27

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/NamespaceManager.php

Above notes are mere suggestions because #1 doesn't contain enough information to make a sufficient analysis.

Yeah, the namespace not being set correctly would explain why the data does not show in queries.

We really need to have this written down decently so people know how to upgrade.

I'm considering this bug a blocker for the SMW 1.9 rel (only bug on that list, though there are some other non-bug blockers as well).

Nemo: can you have a look at http://semantic-mediawiki.org/wiki/Thread:Help_talk:Installation/MW_1.22_and_SMW_1.9beta_install/upgrade ?

Then modify your namespace config appropriately and see if that fixes the issue?

update.php results in the following issue for translatewiki.net:

Checking table bw_smw_fpt_askdu ...

Table not found, now creating...

A database query error has occurred.
Query: CREATE TABLE translatewiki_net.bw_smw_fpt_askdu (s_id INT(8) UNSIGNED NOT NULL,o_serialized VARBINARY(255),o_sortkey DOUBLE) TYPE=InnoDB
Function: SMWSQLHelpers::createTable
Error: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'TYPE=InnoDB' at line 1 (localhost)

The problem is that you are using $wgDBTableOptions directly, and thus it does not get the compatibility fix from DatabaseMysqlBase::getDefaultSchemaVars(). It is of course easy for us to uptdate $wgDBTableOptions to correct format.

We were using a config feature that was removed in MySQL 5.1, according to http://bugs.mysql.com/bug.php?id=17501.

We had:

DatabaseSettings.php:$wgDBTableOptions = "TYPE=InnoDB";

We have:

DatabaseSettings.php:$wgDBTableOptions = "ENGINE=InnoDB";

This is no longer an issue for translatewiki.net, but Semantic MediaWiki should probably be updated so that other installations do not run into the same issue.

Thanks for pinpointing the issue!

and thus it does not get the compatibility fix from DatabaseMysqlBase::getDefaultSchemaVars()

Indeed. Any suggestion on how to make use of this fix? The MediaWiki code does not seem to facilitate usage from the SMW use case. We could put the below replacement in SMW as well, which might be the most pragmatic approach, though definitely not a clean solution.