Support table and field-level charsets and collations

[Synchro]

I have generated migrations from my DB, and all works well, but I didn't notice until later that it dropped all info about charsets and collations. I saw a mention of field and table level charsets in #23, but it looks like it's not actually present.

My database has a default charset and collection of utf8mb4 / utf8mb4_unicode_ci. A table might be created like this:

CREATE TABLE `products` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `serial` varchar(64) CHARACTER SET ascii COLLATE ascii_bin DEFAULT NULL,
);

and I would want this to generate a migration along the lines of:

        Schema::create(
            'products',
            function (Blueprint $table) {
                $table->bigIncrements('id');
                $table->string('serial', 64)->nullable()
                    ->charset('ascii')
                    ->collate('ascii_bin');
            }
        );

but it comes out like this:

        Schema::create(
            'products',
            function (Blueprint $table) {
                $table->bigIncrements('id');
                $table->string('serial', 64)->nullable();
            }
        );

This was unexpected, but wasn't too damaging for me, but I can see this being a problem in many DB schemas, particularly where case-sensitivity is important. I'm not sure if this is a bug or a feature request - Are field-or table level charsets and collations meant to be supported?

[kitloong]

Hi @Synchro , I am very sorry for my late reply, which took place a month ago.

By default, the generator will generate migrations without considering the DB charset/collation.

If you would like to generate migrations as you described, you need to run the generator with the option --use-db-collation.

When using this option, it will compare the DB charset/collation with your Laravel configuration. If they matched, nothing will be changed. Else, it will generate migrations with respect to your DB charset/collation.

Please let me know if the option doesn't work for you.

[Synchro]

Why wouldn't this be the default? Surely the intention is to create migrations that reflect the database schema accurately, and that would include charsets and collations? I can see that you might want to not do it as a special case, but that should be rare.

[kitloong]

Hi @Synchro , you raise a valid point.

However, when I started working on this project, the charset and collations were not being generated as part of the migrations.

To strike a balance between consistency and offering additional functionality, I made the decision to maintain the original behavior as the default, and I introduced the --use-db-collation option.

In summary, this allows users who want to generate migrations with respect to their database's charset and collation to do so while keeping the original behavior.