-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DOCS]: Suggest using utf8mb4_bin
for collation
#28627
Conversation
For MySQL, suggest using `utf8mb4_bin` for collation, rather than `utf8mb4_general_ci`, because the latter is case insensitive, and can break assumptions in various parts of Gitea. Such as branch names: branch names are case sensitive in git, but with a case insensitive collation, and the branch names stored in the database, repositories with branch names that differ in case only can lead to internal errors. This little change updates the documentation only, as a first step of addressing the problem. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
I have a proper fix in the works too, but that's going to take a bit longer, and I wanted to get the documentation update out ASAP. |
This change is far from ideal. For example, the And this problem is a longstanding known problem, see: Convert branch table name column to a new collation for mysql/mssql to support case sensitive because branch names are case sensitive #25623 I guess maybe it just needs more time to mature. |
Yes, I intentionally did not update As for #25623: I think it is too limited, as it only changes the branch name column. Since other databases (Postgres & SQLite) are case sensitive by default, I think a better solution would be to change every collation to |
That's the problem. Since it is incomplete, it doesn't really help. To resolve the problem, it should be fixed fundamentally, eg: by default use case-sensitive column types. If only the document is changed, the problem is:
So, it needs a full fix. |
It helps new installations, by making them use a case-sensitive collation (if following the docs). My point is that helping new installations and helping existing ones can be treated separately, and the former doesn't need a full fix.
Fair enough. I can adjust the PR to touch only the database preparation parts, and then the docs and
Not if they follow the docs and set the correct collation when creating the database. If you create the database with collation set to
Again, existing users are not a target for this PR. This PR's only aim is to help new instances by not recommending the wrong collation in the docs. That's all.
So lets remove docs then? o.O
Okay. |
Actually, many (maybe most) new Gitea instances are created by docker. So it still needs a code-level fix, either partial or full. However, if we only say For a quick patch, it could be like this: Make table column branch.name case sensitive #28633 I also agree that it's better to make all database column case-sensitive by default. |
For MySQL, suggest using
utf8mb4_bin
for collation, rather thanutf8mb4_general_ci
, because the latter is case insensitive, and can break assumptions in various parts of Gitea. Such as branch names: branch names are case sensitive in git, but with a case insensitive collation, and the branch names stored in the database, repositories with branch names that differ in case only can lead to internal errors.This little change updates the documentation only, as a first step of addressing the problem.