[2.1] Upgrader - Set db_character_set#9278
Open
sbulen wants to merge 1 commit into
Open
Conversation
Signed-off-by: Shawn Bulen <bulens@pacbell.net>
Contributor
Author
|
Some screenshots.... This is a screenshot of the serialized strings in log_actions before the upgrade: 
Log actions after the upgrade... Items with non-utf8 chars were lost: 
With this PR, the characters are maintained: 
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Spun off from #9271
Mid-upgrade, $db_character_set was getting erroneously set to 'utf8' in step 2 under some circumstances. So, if there were non-utf8 characters, updates to that data could mangle or delete the data. This is mostly visible during the json conversion, where lots of latin1 characters may be encountered. Both MySQL & MariaDB are affected.
In 2.0, $db_character_set was not set by the SMF installer. So it's blank for a lot of forums. The 2.1 upgrader, when the 'Migrate to new Settings.php' box is checked, detects the blank $db_character_set and defaults it to 'utf8'. This causes the upgrader to issue a SET NAMES for 'utf8'. Database updates prior to the utf8 conversion could cause issues.
So, this PR detects what $db_character_set should be, then sets it in Settings.php. That way the Settings.php migration leaves it alone. It is then properly set to 'utf8' in a later step, after the utf8 conversion completes.
If approved, I'll work on a 3.0 version.
Note there is still one odd wrinkle related to charsets/collations I haven't figured out... During the utf8 conversion, MariaDB is setting all the tables to utf8mb3_uca1400_ai_ci instead of utf8mb3_general_ci, the SMF 2.1 default. They are not synonymous. Haven't figured out why yet.