Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 2.3
-
Component/s: Database SQL/XMLDB
-
Labels:None
-
Testing Instructions:
-
Affected Branches:MOODLE_23_STABLE
-
Fixed Branches:MOODLE_20_STABLE, MOODLE_21_STABLE, MOODLE_22_STABLE
-
Pull from Repository:
-
Pull Master Branch:
-
Pull Master Diff URL:
-
Documentation link:
Description
From the forums (http://moodle.org/mod/forum/discuss.php?d=205378), it looks like if there is a 'double unsigned' field in the DB then it causes the whole upgrade to fail.
I suppose this is because we don't support unsigned double in the db? In any case maybe it shouldn't cause the whole upgrade to fail:
error/invalidmysqlnativetype
More information about this error
Debug info:
Error code: invalidmysqlnativetype
$a contents: double unsigned
Stack trace:
line 641 of /lib/dml/mysqli_native_moodle_database.php: dml_exception thrown
line 534 of /lib/dml/mysqli_native_moodle_database.php: call to mysqli_native_moodle_database->mysqltype2moodletype()
line 460 of /lib/dml/mysqli_native_moodle_database.php: call to mysqli_native_moodle_database->get_column_info()
line 522 of /lib/dml/moodle_database.php: call to mysqli_native_moodle_database->get_columns()
line 1551 of /lib/dml/moodle_database.php: call to moodle_database->where_clause()
line 60 of /lib/db/upgradelib.php: call to moodle_database->count_records()
line 232 of /lib/db/upgrade.php: call to upgrade_mysql_fix_unsigned_columns()
line 1481 of /lib/upgradelib.php: call to xmldb_main_upgrade()
line 275 of /admin/index.php: call to upgrade_core()
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Aha, found this:
http://bugs.mysql.com/bug.php?id=42758
That seems to be EXACTLY the problem (float columns incorrectly returning "xxx unsigned" in the data_type column. Was fixed in 5.1.33... waiting to get feedback about Doug's mysql version.
It's in 5.1.33 release notes: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-33.html
Ciao 
Since Ubuntu LTS 10.10 (support just ending) has 5.1.63 and Debian has 5.1.63, I think this is fine.
Bumping to 5.1.33 on release notes.
Sending to integration...
Integrated, but not yet tested. Will start that shortly.
MySQL 5.1.33 requirement added to http://docs.moodle.org/23/en/Upgrading_to_Moodle_2.3#System_requirements
Oh, we have a HORRIBLE message!
"version 5.1.33 is required and you are running 5.0.51.24.2
MySQL 4.1.16 is the minimum version required for Moodle 1.6 in order to guarantee that all data can be converted to UTF-8 in the future."
Is it possible to evaluate the proposed alternative, the hack in the Moodle code?
For those relying in RHEL / CentOS servers:
- 6.x, MySQL v5.1.61 => OK
- 5.x, MySQL v5.0.95 => KO. Version 5 will be EOLed at 2017/03/31 (https://access.redhat.com/support/policy/updates/errata/, http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d) and I guess there are several RHEL / CentOS 5 based servers now serving Moodle 2.2-.
Tested environemnt checks on all branches. Upgrade from and install was prevented on older version.
Though we do have that horrible mysql message - but that is not enough to block this issue.
(I'd like to express my gratitude to snapshot.debian.org for making testing of this issue really easy!)
Much as I'd like to be able to support every database and browser for ever, we do need to move forward occasionally to save our sanity and focus on functionality and more important bugs.
We haven't bumped MySQL requirements for 1.5 years, since Moodle 2.0.
@Martin: OK, understood.
Added extra commit to the 4 branches to delete the MySQL 4.1.6 explanation, clearly outdated.
To test, on any version, force the mysql to fail and you will get the standard error message "version xxxxx is required and you are running yyyyy" instea of the 4.1.16 & unicode one.
Ciao
Integrated and tested that change
Yay. just in time for Moodle 2.3 release! Many thanks!
Closing as fixed, ciao
@Helen: please look at http://docs.moodle.org/23/en/Installing_Moodle#Software, maybe you've already planned it but it misses to mention the new MySQL version. There are other things there to be changed like 2.2 => 2.3 and MOODLE_22_STABLE to MOODLE_23_STABLE. I've not opened a new trivial issue, wondering to have done the right thing 
.
Hmm, there are further reports of this problem in: http://moodle.org/mod/forum/discuss.php?d=205378
For those wondering we hit this same bug and Eloy's hack did allow us to complete the upgrade (after disabling the new environment requirement).
Thanks Matteo, http://docs.moodle.org/23/en/Installing_Moodle updated
While I think this can be easily fixed by one of these:
1) changing the count_records() @ upgradelib to get_field_sql() (to avoid calling metadata stuff). Tricky.
2) changing the mysqltype2moodletype() method to clean the type with something like:
$mysql_type = trim(str_replace('UNSIGNED', '', (strtoupper($mysql_type))));I've asked for more information @ the forums, because it seems that the offending server is returning wrong information in the "data_type" column of the information_schema.columns table. I've tried here creating all sort of doubles/floats, with and without specs and I get constant "double" there, never "double unsigned" (that is the cause of the problem).
So perhaps it's a MySQL bug... let's see. My vote goes to apply 2) above, no matter or further investigations to detect the offending version of MySQL.
Ciao