Repository navigation
Schema: widen the user name columns on servers upgraded from 1.5 - #2005
Merged
Merged
Conversation
Step 279 widens users.uName and users.uCreateBy from 1.5's VARCHAR(40) NOT NULL to VARCHAR(255) NULL. A 1.5.x server arrives with a count past 279 and skips it, and SchemaReconciler never retypes an existing column. So an upgraded server kept a 40-character user name, where a fresh install allows 255. Step 446 repeats the ALTER. Widening keeps every stored value, and on a server that already ran 279 it changes nothing. Refs #2000 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Problem
On a server upgraded from 1.5,
users.uNameandusers.uCreateBystayVARCHAR(40) NOT NULL. A fresh 1.6 install hasVARCHAR(255) NULL. A user name longer than 40 characters, such as an LDAP or OIDC login that is a full email address, does not fit. Found in #2000.Cause
Step 279 does the widening. A 1.5.x server carries a schema count past 279 (1.5.10.2518 is at 288), so the updater skips it.
SchemaReconcileradds missing tables and columns, but it never retypes a column that exists.Fix
Step 446 repeats step 279's ALTER, and
FOG_SCHEMAgoes to 446. On a server that already ran 279, the statement changes nothing.Why no value is lost
The change only makes the limit larger. Every stored value already fits in 40 characters, so the server copies it unchanged. Removing
NOT NULLchanges no stored value either. TheUNIQUE KEY nameindex stays, and at 255 characters in utf8mb3 it is 765 bytes, which is inside InnoDB's 767-byte limit.Tests
userstable holding a 3-character name, a 40-character name and a non-ASCII name was widened onmariadb:10.5andmysql:8.0. Every row'sMD5(uName)is the same before and after. A 72-character name inserts underSTRICT_TRANS_TABLESafterwards. The final columns match the manifest:varchar(255) DEFAULT NULLwith the unique key.tests/schema-gate.test.php: FOG_SCHEMA 446 covers the highest step (446).OpenAPI::document()is not affected.Refs #2000
🤖 Generated with Claude Code