Skip to content

Develop candidate 02 24 2019#927

Closed
mgage wants to merge 99 commits into
openwebwork:developfrom
mgage:develop_candidate_02_24_2019
Closed

Develop candidate 02 24 2019#927
mgage wants to merge 99 commits into
openwebwork:developfrom
mgage:develop_candidate_02_24_2019

Conversation

@mgage
Copy link
Copy Markdown
Member

@mgage mgage commented Feb 25, 2019

This should replace PR #908. It changes fewer files since I have already committed the bulk of the changes in to the copyright symbol.

goehle and others added 30 commits June 20, 2016 14:13
… and mess up the database. Note: We do not need decode from thaw because as sequences of bytes nothing changes. (I think.)
…ch/webwork2 into locbug

Conflicts:
	courses.dist/modelCourse/course.conf
added [qw(Encode::Encoding)] to ${pg}{modules}) in defaults.config as…
…lop_uft8_ver2

# Conflicts:
#	lib/WeBWorK/ContentGenerator/Instructor/SendMail.pm
#	lib/WeBWorK/Utils.pm
mgage and others added 11 commits January 1, 2019 21:40
On the other hand if the file contains a character (such as @) which is an invalid utf8 character then issue a warning to
the html page. (Since course.conf often has an incorrect @ instead of © this results in an error for each course until those files are fixed.)
using © instead of © (the latter doesn't alwayswork with utf8 )
this change was undone in some some places during recent merges.
also have a "home directory" printout  for debugging.
…pty_passwords_during_checkPassword

PR 911+910+904 hotfixes to mgage new_develop_candidate_01_01_2019
…base

use the utf8mb4 charset. The new file will be added to the running Docker
MariabDB 10.1 container using changes to be made to docker-compose.yml in
a following commit.
	mysql_enable_utf8    ==>    mysql_enable_utf8mb4
	"SET NAMES 'utf8'"   ==>    SET NAMES 'utf8mb4'"
	modify the length of several VARCHAR columns so key length < 1000
	   as utf8mb4 reserves 4 bytes per character.
These changes sufficed to allow (in a Docker test system):
	creating and using the admin course in a new MariaDB 10.0 database
		which was set to use utf8mb4 as the default charset,
	running OPL_update,
	creating a test course and creating a homework set with the question
		setMAAtutorial/hello.pg in it,
	creating a user whose name needs UTF8 characters, and
	submitting a UTF8 encoded string as an answer to
		setMAAtutorial/hello.pg and storing the UTF8 answer in the
		past_answer table.
Note: The Docker test was done after the docker-compose.yml was modified,
which is in the following commit.
database to use utf8mb4. This needs to be done BEFORE
the Docker database storage volume is created.

A special version called
	docker-compose.yml.specialUTF8MB4-db-storage
can be used to replace docker-compose.yml, and will
change the name of the database container, the database
named storage volume, and make related settings. Replace
docker-compose.yml with the file will force Docker to
run the containers in a manner which will not intefere with
the non-utf8mb4 database used by the prior configuration.
That approach would allow one to switch between the use of
Docker containers using a utf8mb4 database and using an
old style database, just by using the "correct" settings
in docker-compose.yml for each "case".
To allow the 1000 byte limit for keys, the OPL_local_statistics was
changed to use ENGINE=MyISAM. That change allowed reducing the
source_file column from varchar(255) to varchar(245), while the
767 bytes key limit of ENGINE=InnoDB as was used by this table and
by OPL_global_statistics.sql (at present) would have limited this to
about 191 characters.

The OPL_problem_user table had 3 keys changed from using 100 characters
each to using only 80 characters each. The same changes were already
made to lib/WeBWorK/DB/Record/PastAnswer.pm for the same reason. Only
the first 245 characters of source_file are used as a key. Finally,
the CHARACTER SET of OPL_problem_user was explicitly changed from ascii
to utf8mb4.

The saved version of OPL_global_statistics.sql needs to be hand modified
as follows, until the GitHub master branch has these changes made. Only
after those changes can the file be loaded into a utf8mb4 database.
        utf8    => utf8mb4
        255     => 245
  ENGINE=InnoDB => ENGINE=MyISAM
=================================

10c10
< /*!40101 SET NAMES utf8mb4 */;
---
> /*!40101 SET NAMES utf8 */;
24c24
< /*!40101 SET character_set_client = utf8mb4 */;
---
> /*!40101 SET character_set_client = utf8 */;
26c26
<   `source_file` varchar(245) NOT NULL,
---
>   `source_file` varchar(255) NOT NULL,
31c31
< ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4;
---
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
@taniwallach taniwallach self-requested a review March 6, 2019 16:13
@taniwallach
Copy link
Copy Markdown
Member

I made a PR to @mgage tree, to get things to work (at least in Docker) when a uft8mb4 database is used.
See mgage#24

There is a special docker-compose.yml.specialUTF8MB4-db-storage included which can be used to avoid the need to delete a current named Docker volume of SQL data by using a different container/volume name for the utf8mb4 testing.

With those changes (and the hacks to bypass the missing XML::Simple module in the current Docker image) I could (in a Docker test system):

  • creating and using the admin course in a new MariaDB 10.1 database which was set to use utf8mb4 as the default charset,
  • running OPL_update
  • creating a test course and creating a homework set with the question setMAAtutorial/hello.pg in it (selected as it takes a sting answer)
  • creating a user whose name needs UTF8 characters, and
  • submit a UTF8 encoded string as an answer to setMAAtutorial/hello.pg and later see the stored UTF8 answer in the course's past_answer table.

The testing was done when PG was using the branch from openwebwork/pg#390

Overall, this seems a pretty good indication that things basically work with this set of UTF8 support for both webwork2 and pg.

I have been running a development server using the older (early 2019) branches with good success.

In my opinion, we won't find many more of the issues with the UTF8 support until more people are testing the code on servers which get a reasonable amount of usage.

Note: When I tried to include XML::Simple near the start of the first
"cpanm install" line, there was an error:
   Building and testing XMLRPC-Lite-0.717 ... ! Installing XMLRPC::Lite failed.
   See /root/.cpanm/work/1551887935.125/build.log for details.
   Retry with --force to force install it.
so it was put into a second "cpanm install" line.
@mgage
Copy link
Copy Markdown
Member Author

mgage commented Mar 12, 2019

This is replaced by PR #930

@mgage mgage closed this Mar 12, 2019
@mgage
Copy link
Copy Markdown
Member Author

mgage commented Mar 12, 2019

replaced by pr #930

@mgage
Copy link
Copy Markdown
Member Author

mgage commented Mar 12, 2019

this is replaced by PR #930

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants