Flyspray

  • Status New
  • Percent Complete
    50%
  • Task Type Bug Report
  • Category Database Queries
  • Assigned To
    peterdd
  • Operating System All
  • Severity Low
  • Priority Medium
  • Reported Version 1.0-rc10
  • Due in Version 1.0-rc11
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray
Opened by peterdd - 07.11.2022
Last edited by peterdd - 08.11.2022

FS#2669 - user and registrations tables: Illegal mix of collations

The ajax call to check if a username is taken fails currently on https://bugs.flyspray.org when trying to fill the user registration form.
(beside the fact the registration confirmation loop is not working as mail server not correct configured)

Query {
    SELECT count(u.user_name) AS anz_u_user, count(r.user_name) AS anz_r_user
    FROM `flyspray_users` u
    LEFT JOIN `flyspray_registrations` r ON u.user_name = r.user_name
    WHERE LOWER(u.user_name) = ? OR LOWER(r.user_name) = ?}
 failed! (Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='

Inconsistency probably due misconfiguration due manual upgrade + manual changes to the database.

Affected: maybe only https://bugs.flyspray.org

I fixed it on bugs.flyspray.org by running SQL commands:

ALTER TABLE flyspray_registrations CONVERT TO CHARACTER SET utf8mb4;

and

ALTER TABLE flyspray_users CONVERT TO CHARACTER SET utf8mb4;

Both now using the servers default collation, so they can be joined again by boths user_name field.

This can be seen as just a quickfix.

Why this happened at all?

I can only speculate about this as I can do some administration only since 2021.

I assume the defaults of mysql tables charsets and collation changed with mysql/mariadb versions and the upgrade scripts does not explicit handle that.

So lets say first it was utf8 and utf8_general_ci,
then utf8 and utf8_unicode_ci
and then utf8mb4 and utf8mb4_unicode_ci.

And when upgrading Flyspray and new tables where created they use the servers new default charset and collation while the older tables and varchar fields keep their old charset and collation which leads to inconsistencies.

And then there where probably manual interventions by admins (from 2003-2021?) who fixed/changed charset/collation on certain tables and fields manually by running SQL commands.

How it should be fixed

The Flyspray install and upgrade scripts and xmlschema03 files should contain information and settings for charset and collation for the table fields and upgrade scripts and should convert wrong charset and collation fields during an upgrade if they are wrong in the database.

Sadly ADOdb’s xmlschema03 lacks configuring and handling yet, so this must be done by the upgrade PHP scripts after running xmlschema03 xml files.

How it will be handled meanwhile

Extending Admin Toolbox→Checks sections to compare the current database with the intended configuration.

So admins can fix tables and field charset and collation where required.

Such inconsistency could be detected by admin checks - tab.

I would like to see that field users.user_name and registrations.user_name just be ascii (in mysql) and only accepts allowed username characters.

Project Manager

fixed it on bugs.flyspray.org

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing