Last modified: 2013-12-19 17:34:03 UTC
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.
James, any idea?
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.
https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/53
