Infer omitted column charset from collation

[morozov]

Q	A
Type	bug

Fixes #5338.

[greg0ire]

What does null mean here? "This collation has no charset"? "We don't know about this collation"? Both? If both, should the second case result in an exception?

[morozov]

What does null mean here?

"This collation has no charset" is impossible, so it's "We don't know about this collation".

[…] should the second case result in an exception?

It doesn't have to. Should strpos() throw an exception if the substring is not found? The calling code handles null by not updating options, so if the collation is invalid, the DDL will eventually fail once it hits the database.

If we decide to throw an exception here, how do we unit-test the comparator without the database connection? Right now, we supply it with a provider that always returns null, which is fine because no unit tests rely on this feature.

[greg0ire]

It's clearer, thanks for the explanation.

[Ocramius]

Note to self: this will do something alike:

$column->setPlatformOptions([
    'collation' => 'utf8_bin',
    'charset' => 'utf8',
]);

What I found while testing locally (couldn't investigate further, so this is mostly a note to self, in order to figure out how to debug + open an issue about it), is that the order of the platform options may be scrambled.

Sometimes, 'collation' comes first, other times, 'charset' comes first.

This seems to trip the whole schema comparison somewhere, although I couldn't pinpoint it yet.

EDIT: errata: it's just the table charset being diffed with my own column definition. Very confused about it, need to check deeper.

EDIT2: possibly found the culprit, and it's possibly a weird edge case that doesn't really need fixing. Given a table like this:

CREATE TABLE a_table
(
   a_column VARCHAR(255) COLLATE utf8_bin NULL,
)
    charset = utf8;

The following table definition seems to always produce a diff:

new Table(
    'a_table',
    new Column(
        'a_column',
        Type::getType(Types::STRING),
        ['platformOptions' => ['collation' => 'utf8_bin, 'charset' => 'utf8']]
)

This makes sense, because we don't want to "remove" the charset from columns that have an utf8 charset, and are already part of a table with utf8 charset: we mostly want to ignore that.

This will produce ALTER statements like:

ALTER TABLE a_table CHANGE a_column a_column VARCHAR(255) CHARACTER SET utf8 DEFAULT NULL COLLATE `utf8_bin`;

Next up for me is dusting off the DBAL test suite and making it reproducible (plus new issue)