To test:
Perform a clean install of the latest 3.5 version (tested with the master branch as of 173ab1a) on a system that has a mysql version that supports utf8mb4. Dump the database schema to a file: mysqldump -d {database} > 3.5-install.sql
.
Remove the previous install. Perform a clean install of version 3.4.5 on a system that has a mysql version that supports utf8mb4. Update that version to the latest 3.5 version. Again dump the database schema to a file 3.5-update.sql
.
Compare the schema files: diff -u 3.5-install.sql 3.5-update.sql
.
Note that the 52 columns of type text
in the 3.5-install.sql
file are of type mediumtext
in the 3.5-update.sql
file. Likewise, note that the 6 columns of type mediumtext
in the install file are of type longtext
in the update file.
Note that, after updating from 3.4 to 3.5, going to Extensions->Manage->Database
shows the following error:
1 Database Problem Found.
Other Information
Table 'fyu2o_user_profiles' does not have column 'profile_value' with type 'TEXT'. (From file 3.3.4-2014-08-03.sql.)
So the issue here is that text-type columns have been converted to larger sizes when updating to 3.5 versus those found in a fresh 3.5 install (which agree with v. 3.5's installation/sql/mysql/joomla.sql).
For example, #__user_profiles.profile_value
is of type text
on a fresh install, but is of type mediumtext
after update.
The type conversion upon update is occurring because of lines in administrator/components/com_admin/sql/updates/mysql/3.5.0-2015-07-01.sql that convert tables from utf8 to utf8mb4. So the relevant line for the example above is:
ALTER TABLE `#__user_profiles` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
I don't have a specific suggestion for what, if anything, should be done. There are, however, 3 possibilities that come to mind:
Do nothing and allow users who update to have a different schema from those who install fresh. Would this cause problems down the road? I don't know. It obviously is resulting in the one error shown above, as was found in Extensions->Manage->Database
.
Modify installation/sql/mysql/joomla.sql
so that it matches the schema users are left with after updating. This probably results in the use of larger text-types than is really necessary. I don't know what impact, if any, that might have on database performance or efficiency.
It should be possible to avoid the type-conversion by not using the CONVERT TO CHARACTER SET
SQL commands, but instead to simply alter the character set of the tables and columns. Unfortunately, this makes the SQL statements more complicated. The SQL for the example above would become:
ALTER TABLE `#__user_profiles` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci,
MODIFY `profile_key` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL,
MODIFY `profile_value` text CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL;
Labels |
Added:
?
|
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-11-18 21:18:14 |
Closed_By | ⇒ | roland-d |
@zjw I am going to close this thread as I am incorporating the changes to the SQL file in issue #8472
Thanks for reporting this as well.