Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-137

APIManager: Multilingual Character Input Error on 3scale Admin Console

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • 2.0 GA
    • System
    • 20
    • Engineering
    • Hide

      Put Japanese characters in the description field of service create from 3scale admin console.

      Show
      Put Japanese characters in the description field of service create from 3scale admin console.
    • 3scale 2019-12-09, 3scale 2019-12-23, 3scale 2020-01-13, 3scale 2020-01-27, 3scale 2020-02-03, 3scale 2020-02-17, 3scale 2020-03-09

      Related issues:

      https://github.com/3scale/system/issues/8471
      https://issues.jboss.org/browse/THREESCALE-604 – fixed in 2.2 GA

      One case

      My Japanese customer has been trying 3scale AMP On-Premises for this month.
      And they said they got below error when they input Japanese characters in the form "description" at service create on the web console.

      ActiveRecord::StatementInvalid (Mysql2::Error: Incorrect string value: '\xE7\x92\xB0\xE5\xA2\x83...' for column 'description' at row 1: INSERT INTO `services` (`account_id`, `state`, `name`, `system_name`, `description`, `created_at`, `updated_at`) VALUES (2, 'incomplete', 'M3-APP-ST0', 'M3_APP_ST0', 'M3-APP-ST0環境。', '2017-05-30 06:28:31', '2017-05-30 06:28:31')):
      app/controllers/api/services_controller.rb:43:in `create'
      lib/three_scale/middleware/multitenant.rb:116:in `_call'
      lib/three_scale/middleware/multitenant.rb:111:in `call'
      lib/action_dispatch/rails5_ssl.rb:86:in `call'

      Is it a bug? Any workaround?

      Dev notes

      Mysql only (postgres and oracle are fine) does not support utf8 mb4 chars by default.
      So Hebrew, japanese and basically utf8 mb4 needing language cannot be saved in MySQL.

      A possible workaround would be to support ut8 mb4 chars for the DBs that support it, and have a validation (ruby/rails, before reaching the DB) for MySQL to return a proper error message instead of crashing.

      Another possibility is migrating mysql to postgres both for saas and for on-prem and not letting the customers useit on-prem for future releases, but that should be Product who decided it.

      Real fix: we should migrate the whole database to utfmb4 on mysql. We can follow advices from Percona blog https://www.percona.com/blog/2018/04/10/migrating-database-charsets-to-utf8mb4/

      Mysql8 supports by default utf8mb4
      Postgres and Oracle databases do not have this issue.

      That means we need to do a migration script for SaaS and for customers on-premises, which means taking care of no data loss:

      • indices must be reworked
      Notice I’ve enabled the variable innodb_large_prefix. This is important because InnoDB limits index prefixes to 768 bytes by default. If you have an index based in a varchar(255) data type, you will get an error because the new charset exceeds this limit (up to four bytes per character goes beyond 1000 bytes) unless you limit the index prefix. To avoid issues during data load, we enable this variable to extend the limit to 3072 bytes.
      • text fields size must be ajusted
      • it will need a maintenance window

      Simple idea would be to have a maintenance window:

      1. stop all services
      2. mysqldump the old database
      3. Changing characterset in the dumpfile to utfmb4 everywhere
      4. load the dump into a new database
      5. start all services

            Unassigned Unassigned
            yhasegaw_jira Yusuke Hasegawa
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: