[9.x] Enhance column modifying

[hafezdivandari]

This PR does:

• Add support for changing column type to double
• Add support for changing column type to tinyText.
• Fix a issue when changing column type to timestamp:
  • The SQL contained charset/collate: TIMESTAMP SET utf8mb4 COLLATE utf8mb4_unicode_ci
• Fix a issue when changing column type to binary:
  • on MySQL, the type was LONGBLOB instead of expected BLOB

PS: I added tests for all adds and changes.
PS: changes to binary reverted.

[driesvints]

Won't this change the behavior for apps who have already run their migrations in production?

[hafezdivandari]

@driesvints if they have already run their migrations, how this change the behavior of those apps?

Currently, when adding a binary column it is always a BLOB equivalent column. but when changing to binary column it depends on the previous column's length and default to LONGBLOB if it has no length. for example:

Schema::create('tests', function (Blueprint $table) {
    $table->string('string_to_binary');
    $table->integer('integer_to_binary');
    $table->binary('binary_column'); // is always `BLOB`
});

Schema::table('tests', function (Blueprint $table) {
    $table->binary('string_to_binary')->change();  // changes to `TINYBLOB` because it already has the length of 255.
    $table->binary('integer_to_binary')->change(); // changes to `LONGBLOB` because it already has no length.
});

Please check this function on Doctrine DBAL;

I think it is inconsistent behavior but if you think this is the expected behavior or is a breaking change, I can revert changes to binary column modifying. Please let me know. Other changes are not breaking at all.

[driesvints]

Their migrations which are part of their app will still be run in development. If they run them in development after this PR is merged, their development databases will be out if sync with production.

[hafezdivandari]

OK, I reverted changes on binary I'll send that to master later.