[MDEV-13341] information_schema.columns Column_default now return 'null' instead of null Created: 2017-07-18  Updated: 2017-10-12  Resolved: 2017-07-18

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 10.2.7
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Diego Dupin Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes CONJ-506 column metadata return 'null' in plac... Closed
is caused by MDEV-13132 Information Schema does not show whet... Closed
Relates
relates to MDEV-13244 `DEFAULT` & `COMMENT` doens't work so... Stalled
relates to MDEV-14053 Unquoted NULL default values in infor... Closed

 Description   

10.2.7 version has an issue that doesn't exist in previous version 10.2.6 :
information_schema.columns Column_default now return 'NULL' instead of null



 Comments   
Comment by Elena Stepanova [ 2017-07-18 ]

It was an intentional change made in scope of MDEV-13132. Does it cause any troubles?

Comment by Jérôme Billiras [ 2017-07-18 ]

Hi,

I think it will cause troubles to many peoples.

Doctrine ORM (PHP) just gone crazy to update a schema structure
SequelPro (Mac) see nullable field with default to "NULL" instead of NULL

That's tools I use everyday but I'm pretty sure that make troubles in many other tools

Comment by Sergei Golubchik [ 2017-07-18 ]

Yes, we're painfully aware of that

See MDEV-13132 — it was a genuine bug, because someone has misread the standard years ago. And in 10.2 the problem has become critical. MariaDB (and MySQL) violates the SQL standard and behaves differently from all other databases that we've tried (explained in MDEV-13132).

We've tried to reduce the damage by doing this change only in 10.2 (not in 10.1 or 10.0 or 5.5) and by keeping old behavior of SHOW COLUMNS (because it's non-standard, so there're no rules for it). Applications can switch to SHOW COLUMNS easily. Or adapt to use the new behavior, because old one cannot describe default values unambiguously.

Comment by Sébastien Vanvelthem [ 2017-08-26 ]

Hi Sergei, make sense.

just released a P/R for doctrine: https://github.com/doctrine/dbal/pull/2825 if anyone face the same issue.

Comment by Sébastien Vanvelthem [ 2017-08-28 ]

Hi Sergei,

I digged a bit into implications by fixing doctrine... One thing that I would like you to be aware:

> We've tried to reduce the damage by doing this change only in 10.2 (not in 10.1 or 10.0 or 5.5)

Two things:
1. In 10.2.6 (stable) it was working... yet I understand. But this fix have a lot of implications
2. Packaging issue, the official ppa set a version like '5.5.5-10.2.8-MariaDB-10.2.8+maria~xenial-log'. Which means that from PHP, we cannot trust the `mysqli->server_version` (returns 50505), but need to parse 'mysqli->server_info' with so many packaging differences (10.0.15-MariaDB-1~wheezy, ...). This is really painfull. I know this is not directly related, but if the packaging version pretend to be compatible with 5.5.5, it must be the case. Otherwise you should repackage with '10.2.8-MariaDB-10.2.8+maria~xenial-log' or '10.2.8-MariaDB+maria~xenial-log

Just to let you know... but mariadb will probably suffer from this.

Comment by Sergei Golubchik [ 2017-08-28 ]

What client library are you using? All mariadb client libraries strip "5.5.5-" prefix from the version (it was a hack to fix mariadb-mysql replication, where mysql code only looked at the first digit of the version, so 10.0 was below 3.23, and rejected as "too old").

Comment by Sébastien Vanvelthem [ 2017-08-28 ]

Thanks for pointing out, I understand better now... But still it's not ideal...

On ubuntu xenial, the libmysqlclient package I have is libmysqlclient20 with proposed versions:

  • 5.7.19-0ubuntu0.16.04.1 (from xenial update - this is what I have on my test system)
  • 5.7.11-0ubuntu6 (from xenial)

See here.

I don't remember installing it (generally just using: "sudo apt install mariadb-server libmariadbclient-dev" with the 10.2 ppa). But I'm pretty sure it might have happened when I installed 'mysql-workbench-community'. Needs more tests to be sure. Anyway my php is using 'mysqlnd', see below:

FYI tested PHP versions are PHP "7.1.8-2+ubuntu16.04.1+deb.sury.org+4" and "7.2.0beta3" (both from ondrej ppa).

Important, for PHP7.1 the client is 'mysqlnd 5.0.12-dev - 20150407' (not dynamically linked to libmariadb-dev). Pretty usual.

Anyway, to be sure I attempted installing 'libmysqlclient18' (from mariadb -10.2.8+maria~xenial). As expected it does not help.

So if I understand, it would only work if the mysqli extension is linked to lib<maria>-client (not mysqlnd) ?

Not so simple, mmm.

Let me know, if there's something that could help.

PS:
1. BTW, "select version()" gives a nice '10.2.8-MariaDB-10.2.8+maria~xenial-log'. But I don't want to add an extra query to doctrine.
2. I guess the problem should be solved by using the libmysql-client from mariadb instead of mysqlnd. In another project I was seeing improvements over mysqlnd. Not only with speed but also detection of metadata: see 'here'. Anyway this kind of setup is pretty rare in my experience. Most use mysqlnd.

Comment by Sergei Golubchik [ 2017-08-28 ]

Right. mysqlnd doesn't strip the prefix.

There's a pull request, but it wasn't accepted — https://github.com/php/php-src/pull/1767

Comment by Sébastien Vanvelthem [ 2017-08-28 ]

I see... so I've stripped 5.5.5 prefix on my side too, hope you don't increment later

Generated at Thu Feb 08 08:04:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.