|
David.HallWhat is the analysis of this ?
|
|
Since this is mix of encodings, I asked Bar (Alexander Barkov) for his input on this. He said it was a configuration issue. Starting in 5.5, character set auto-detection was added. It uses localization information from the operating system. He surmises that this is causing our problems. I will be modifying and testing the queries with his suggested changes.
Bar has also created https://jira.mariadb.org/browse/MDEV-10181 to address the issue, as he believes what we have done could/should work.
|
|
I have confirmed that when a table and view use the same character set, the test passes. So, the questions become:
1) Should and can the mixed character set work? – I think they should.
2) Why are the default character set for tables and views different in the same database?
|
|
The character_set_server system variable is set to latin1. The tpch1 database is set to default, so its character set is also latin1. For some reason, character_set_client is set to utf8. Thus views are utf8. There's no way to override this in the create view statement.
The character_set_client is now set by the localization information from the OS, which for Linux, is now utf8.
Until MariaDB is fixed so that these are usable together, we need to set our clients to the same character set as the server. The easiest way to get these tests to pass is to add:
"set names latin1;"
to each script in the view suite.
|
|
Perhaps a more comprehensive solution is to create all our test databases with character set = utf8, or perhaps set character_set_server in my.cnf (probably the easiest of all).
After some tests, It becomes apparent that setting the database character set to utf8 has unintended consequences and requires other scripts to be modified to work.
The easiest solution is to "set names latin1;" in working_tpch1_compareLogOnly/view/mts_view.20.sql
|
|
There are a few other things that cause issues here.
Compare failed - working_tpch1_compareLogOnly/view/mts_view.30.sql
Compare failed - working_tpch1_compareLogOnly/view/mts_view.40.sql
Compare failed - working_tpch1_compareLogOnly/view/mts_view.50.sql
Compare failed - working_tpch1_compareLogOnly/view/mts_view.60.sql
Compare failed - working_tpch1_compareLogOnly/view/mts_view.70.sql
Compare failed - working_tpch1_compareLogOnly/view/mts_view.90.sql
Are failing because of error message changes. these need to be fixed up.
Compare failed - working_tpch1_compareLogOnly/view/mts_view.80.sql
is failing because in the final query, the sort order is different. Since the frontend (mysqld) is doing the sort, I don't think there's anything we can do to fix it.
Compare failed - working_tpch1_compareLogOnly/view/mts_view.sql
is failing for the same issue as 80, plus line 318 contains the following:
select t1.* as a.....
This syntax is no longer supported (* as a). change script to use
select t1.a as a.....
|
|
David.Hall Is this still failing, or has this cleared up ?
|
|
This should be fixed by the 10.1.17 merge. We haven't tested it yet. I'm not in a position just yet to do a pull and test. I will do so as soon as I'm stable locally.
|
|
For the views, there's a lot more going on than character set
|
|
After a bit of analysis, all differences between columnstore and mariadb in these tests can be attributed to design differences and are already documented.
|
|
The fix from MDEV-10309 has fixed the issue
|
mts_view.20.sql