Open pkExec opened 4 years ago
Hello @pkExec,
Thank you for your report. This is not actually a packaging/installation issue but rather, stems from how the schema is defined here: https://github.com/kaltura/server/blob/Propus-16.1.0/deployment/base/sql/01.kaltura_ce_tables.sql Since you were the one to find it, would you like to submit a pull request to the repo in question? That one, you'll be credited for your contribution.
Cheers,
This is not actually a packaging/installation issue
Sorry I wasn't clear enough. The fix to the schema is easy enough, however this will break any existing databases, with garbled characters wherever non-latin language is used. This is how I noticed the problem.
If the schema is upgraded to use utf8 (I may get the time to submit the pull request for that), the packaging needs to use an upgrade script for the existing databases.
The upgrade script needs to run through all the text and varchar columns of all tables, and run a command similar to this:
UPDATE entry SET name = CONVERT(CONVERT(CONVERT(name USING latin1) USING binary) USING UTF8);
Hello @pkExec,
Indeed but these SQL alter/update scripts are also maintained in the server
repo, see:
https://github.com/kaltura/server/tree/Propus-16.1.0/deployment/updates/sql
The postinst
hook in the kaltura-base
package then invokes these. See:
https://github.com/kaltura/platform-install-packages/blob/Propus-16.0.0/RPM/SPECS/kaltura-base.spec#L301
https://github.com/kaltura/platform-install-packages/blob/Propus-16.0.0/deb/kaltura-base/debian/postinst#L86
Cheers,
Bug report
Kaltura uses a mix of latin1 and utf8 in its databases. The result is latin1 characters, stored inside utf8 tables, inside a latin1 database (!) Proof:
See attach file 1
Linux distribution name and version: Ubuntu 16.04.6 LTS, Xenial
Are you using the RPM or deb packages?
For deb based systems:
Is this an all in one instance [single server] or a cluster?