Microsoft .NET Core 1.1 Brings Support For More Linux Distributions, Greater Performance

[AHSauge]

It's based on MySQL which at best has a crapy history. Last time I worked with it, ACID compliance was doggy at best which should come to no surprise as it's written by people who for a while outright called foreign keys stupid. It almost literally stated so in the documentation up until MySQL 3.23/4.1.
Then there are a several issues with non-supported basic features one would expect, faulty/non-compliant implementation or things that are quite a bit outdated. Last time I used it, MySQL only supported a very old version of Unicode for instance. UTF-8 were limited to 3 bytes instead of the usual 4 bytes for instance. Mind you, using Unicode in itself was hell enough.
Essentially MySQL used to be a toy database, and the current MySQL codebase and MariaDB is built on top of that. That's what's wrong with MariaDB

...and how could I forget this? MySQL will happily NOT inform you of errors occuring in your SQL due to missing features or faulty implementation. Sometimes this behaviour seems to be defined as a feature. Take this for example:

A foreign key constraint is not required merely to join two tables. For storage engines other than InnoDB, it is possible when defining a column to use a REFERENCES tbl_name(col_name) clause, which has no actual effect, and serves only as a memo or comment to you that the column which you are currently defining is intended to refer to a column in another table.

...so in other words, if you use the wrong storage engine you get no foreign keys and no warning about it. Nice huh?

[AHSauge]

Yes.



From https://en.wikipedia.org/wiki/UTF-8:

5	31	U+2082080	U+7FFFFFFF	11110xxx	1xxxxxxx	1xxxxxxx	1xxxxxxx	1xxxxxxx

Ah...that explains it. You are quoting UTF-1, not UTF-8. That first table is UTF-1, while the rest are UTF-8.

[AHSauge]

I were a bit quick there. Only the two last tables are UTF-8.

[F.Ultra]

Last time I used it, MySQL only supported a very old version of Unicode for instance. UTF-8 were limited to 3 bytes instead of the usual 4 bytes for instance. Mind you, using Unicode in itself was hell enough.

And MS SQL Server used only UCS-2 until the 2012 version and you still have to prefix all Unicode strings with 'N' like N'ÅÄÖ' for it to work. And how was using Unicode in itself hell enough in MySQL? All you have to do is to call mysql_set_character_set (handle, "utf8"); (unless the server is set to default to utf8 at which point this isn't even necessary) and then start to send utf-8 strings.

[AHSauge]

And MS SQL Server used only UCS-2 until the 2012 version and you still have to prefix all Unicode strings with 'N' like N'ÅÄÖ' for it to work. And how was using Unicode in itself hell enough in MySQL? All you have to do is to call mysql_set_character_set (handle, "utf8"); (unless the server is set to default to utf8 at which point this isn't even necessary) and then start to send utf-8 strings.

I'd say prefixing it is a good thing. You know what's going on and there is no magic happening.
If you've used Unicode i MySQL and actually had a use for it, you should either know what I'm talking about or your data might not be stored as you expect them to be. It's not as simple as calling mysql_set_character_set. This will set the character set for the connection. In other databases you might get away with only that. The server would understand you have character set A to communicate with and character set B to store data with. Most likely A and B are the same, if not it will convert between them. In the case of MySQL you still have to make sure the server, table, field etc. has the expected character set. MySQL will happily accept UTF-8 characters over a connection set to UTF-8 and insert it into a latin1 field. No warning will be given that it's stupid and might give unwanted result. This is before you mix in the fact that MySQL has this super flexible setup where two fields in the same table can have different character set. How do you suppose you'll be able to insert any data into that? Well, if this worked you'd use a set character set in your query and MySQL would convert to the right character set if possible for each field. This just simply doesn't happen, or at least didn't work well back in the days. If you use the same character set in the connection when you pull the data out again, you're most likely fine. However, if you use some other character set you'll soon discover some weird characters in your text.

[Fidelix]

I'd say prefixing it is a good thing. You know what's going on and there is no magic happening.
If you've used Unicode i MySQL and actually had a use for it, you should either know what I'm talking about or your data might not be stored as you expect them to be. It's not as simple as calling mysql_set_character_set. This will set the character set for the connection. In other databases you might get away with only that. The server would understand you have character set A to communicate with and character set B to store data with. Most likely A and B are the same, if not it will convert between them. In the case of MySQL you still have to make sure the server, table, field etc. has the expected character set. MySQL will happily accept UTF-8 characters over a connection set to UTF-8 and insert it into a latin1 field. No warning will be given that it's stupid and might give unwanted result. This is before you mix in the fact that MySQL has this super flexible setup where two fields in the same table can have different character set. How do you suppose you'll be able to insert any data into that? Well, if this worked you'd use a set character set in your query and MySQL would convert to the right character set if possible for each field. This just simply doesn't happen, or at least didn't work well back in the days. If you use the same character set in the connection when you pull the data out again, you're most likely fine. However, if you use some other character set you'll soon discover some weird characters in your text.

Prefixing is a good thing?

All your other points are valid, sorry but this one is a goddamn stretch mate.

[Fidelix]

And by the way, there is a reason MySQL allows different character sets on connection and storage, etc. I won't go into details but it's perfectly valid IMO.

You are also wrong about MySQL throwing no warnings. It depends on your settings and on the client that you are using.
But your point is still valid because I've rarely seen a MySQL-based server being distributed with these warnings enforced.
The client will still throw errors though.

I encountered this problem a couple of times before and thanks to client library warnings it was easy to identify the issue (not so easy to fix).

[F.Ultra]

I'd say prefixing it is a good thing. You know what's going on and there is no magic happening.
If you've used Unicode i MySQL and actually had a use for it, you should either know what I'm talking about or your data might not be stored as you expect them to be. It's not as simple as calling mysql_set_character_set. This will set the character set for the connection. In other databases you might get away with only that. The server would understand you have character set A to communicate with and character set B to store data with. Most likely A and B are the same, if not it will convert between them. In the case of MySQL you still have to make sure the server, table, field etc. has the expected character set. MySQL will happily accept UTF-8 characters over a connection set to UTF-8 and insert it into a latin1 field. No warning will be given that it's stupid and might give unwanted result. This is before you mix in the fact that MySQL has this super flexible setup where two fields in the same table can have different character set. How do you suppose you'll be able to insert any data into that? Well, if this worked you'd use a set character set in your query and MySQL would convert to the right character set if possible for each field. This just simply doesn't happen, or at least didn't work well back in the days. If you use the same character set in the connection when you pull the data out again, you're most likely fine. However, if you use some other character set you'll soon discover some weird characters in your text.

Living in a country with languages that fall well out side of the 7-bit ASCII I'm quite familiar with Unicode on MySQL. While you _can_ set individual columns and tables to a certain charset there is no real need, just set the server default to utf-8 and all columns and tables created from that point on will be utf-8. MySQL will only happily accept utf-8 encoding while not being able to actually store it if you configure the connection to use the non strict mode. Enable strict mode and it will nag like just any other SQL server, the difference with MySQL is that you can set how strict it should be which for certain tasks is a good thing, if you for example run a web store or do financial transactions then fully strict is of course a requirement but in other cases you really want to be insert a couple of rows even though one of the columns might be truncated and what not (i.e I have some situations where we write close to 1M updates per second so there is no time left to let a user manually change a value if it for some reason was malformed and the end users will rather have that row even though some of the data might be garbled than not having the row at all so there are situations where the non strict is a good thing).

The only problem is that most if not all distributions ship MySQL with the strict mode disabled by default and many dos not know that you can enable it and this this myth that MySQL happily accepts erroneous data and therefore is a dangerous server lives on.

[F.Ultra]

I'd say prefixing it is a good thing. You know what's going on and there is no magic happening.

No it's not and no you don't. This is what happens in MSSQL if you send Unicode characters to it with and without the prefix and with varchar or nvarchar (hint there is no errors and it blindly accepts the data in either case even though the stored result is garbage).

https://millistream.com/images/mssql.png

[F.Ultra]

And this is how the same thing in MySQL:

First with strict mode enabled:

MariaDB [db1]> create table a (b varchar(255) CHARACTER SET latin1 default NULL, c varchar(255) CHARACTER SET utf8 default NULL);
Query OK, 0 rows affected (0.51 sec)

MariaDB [db1]> insert into a (b,c) VALUES ('մ','մ');
ERROR 1366 (22007): Incorrect string value: '\xD5\xB4' for column 'b' at row 1

And then with the non-strict mode that is the default on most distributions:

MariaDB [db2]> create table a (b varchar(255) CHARACTER SET latin1 default NULL, c varchar(255) CHARACTER SET utf8 default NULL);
Query OK, 0 rows affected (0.51 sec)

MariaDB [db2]> insert into a (b,c) VALUES ('մ','մ');
Query OK, 1 row affected, 1 warning (0.00 sec)

MariaDB [db2]> show warnings;
+---------+------+------------------------------------------------------------+
| Level   | Code | Message                                                    |
+---------+------+------------------------------------------------------------+
| Warning | 1366 | Incorrect string value: '\xD5\xB4' for column 'b' at row 1 |
+---------+------+------------------------------------------------------------+
1 row in set (0.00 sec)

So as you can see MSSQL behaves the way that you said that MySQL did and MySQL actually gives a warning in non-strict and blatantly refuse to do it in strict-mode.