Fix metadata tests on MariaDB 10.2 and 10.3

[Abscissa]

Travis-ci reports assert failure on the last line in this excerpt from source/mysql/test/integration.d when using MariaDB 10.2 (travis is using 10.2.14) and up:

EDIT: It is NOT this code after all:

	rs = cn.query("select datecol from basetest limit 1").array;
	assert(rs.length == 1);
	Date d = rs[0][0].get!(Date);
	assert(d.year == 2007 && d.month == 1 && d.day == 1);

EDIT: Apparently I read the line number wrong. The above line was never the test failure. This line is where the test failure was.

[Abscissa]

Possibly a result of #90?

[SingingBush]

This may be why my code is breaking on Fedora 28 (mariadb 10.2.14):

Query q = session.createQuery("FROM MyThing ORDER BY created DESC");
auto things = q.list!MyThing(); // <-- dies here

if this is due to the related issue, any idea on when a new release will be available?

[Abscissa]

Hard to say at the moment. I was really hoping to be able to do my long-awaited internal cleanup of the low-level protocol-handling code before anything else relating to that code. But under the circumstances, I don't think I have that luxury. This is too critical-priority.

In any case, I won't have a good idea how involved this will be until I'm actually knee-deep into #90, which I'm going to need to tackle ASAP (probably right after I finish the already-in-progress #65). I'll post updates as I know more.

What I can say though, is that once this is fixed, that will justify an immediate new release.

[Abscissa]

Ugh, something weird going on with this. I haven't even touched the relevant parts of the code, but now travis is showing no problem at all with the code quoted above, but instead there's a failure here.

The good news is most of the tests actually seem to be running fine. Suspecting #90 may not be related after all.

[Abscissa]

Ok, looks like this is considerably less serious than I thought, and probably isn't the issue you're hitting unless you're relying on the metadata module.

Turns out, I originally misread the line number of the assert failure (ie, line 473, not 173) The assert failure was ALWAYS this one, not the one quoted in my original post.

The true issue is that on MariaDB 10.2+ mysql.metadata.ColumnInfo.defaultNull is wrong (which should affect very few users as nothing in mysql-native, aside from some of the tests, actually relies on the metadata module).

On the table used in the tests, the columns are nullable and default to null. But for some reason, on MariaDB 10.2+, instead of getting the normal...

ColumnInfo.defaultNull == true && ColumnInfo.defaultValue is null

...it's getting...

ColumnInfo.defaultNull == false && ColumnInfo.defaultValue == "NULL"

...instead. Which is indeed weird...but should be benign in most cases. All the other null-related tests (and in fact, all the other tests period) pass successfully on MariaDB 10.2 and 10.3.

[Abscissa]

Aha:

From https://mariadb.com/kb/en/library/information-schema-columns-table/

COLUMN_DEFAULT

Default value for the column. From MariaDB 10.2.7, literals are quoted to distinguish them from expressions. NULL means that the column has no default. In MariaDB 10.2.6 and earlier, no quotes were used for any type of default and NULL can either mean that there is no default, or that the default column value is NULL.

So that explains it.