How can I do a migration in laravel 5.5?

after reading error msg in CMD (DOS) and check laravel documentation

error in length i dont know if any one see this error before or not but when i edit length its work

i edit 3 migration as below :-

1 -1- Schema::create('users', function (Blueprint $table) { $table->increments('id'); $table->string('name'); $table->string('username')->unique(); $table->string('email')->unique(); $table->string('password'); $table->rememberToken(); $table->timestamps(); $table->integer('role'); });

and now its

        Schema::create('users', function (Blueprint $table) {
        $table->increments('id')->autoIncrement();
        $table->string('name',200);
        $table->string('username',50)->unique();
        $table->string('email',100)->unique();
        $table->string('password',50);
        $table->string('role',50);
        $table->rememberToken();
        $table->timestamps();

    });

number 2 it was

 Schema::create('password_resets', function (Blueprint $table) { $table->string('email')->index(); $table->string('token'); $table->timestamp('created_at')->nullable(); });

and now its :-

        Schema::create('passwordreset', function (Blueprint $table) {
        $table->string('email',200)->index();
        $table->string('token',200);
        $table->timestamp('created_at')->nullable();
    });

number 3 it was :-

3- Schema::create('tweets', function (Blueprint $table) { $table->increments('id'); $table->integer('user_id')->unsigned()->index(); $table->text('text'); $table->timestamps(); });

now its :-

        Schema::create('tweets', function (Blueprint $table) {
        $table->increments('id')->autoIncrement();
        $table->string('user_id',50)->index();
        $table->string('twetts',255);
        $table->timestamps();
    });

After a couple of over-engineered and overly clever solution attempts, I think the following is a workable solution to the problem.

tl;dr:

• Bookend migrations on either side of migration(s) that build the schema from nothing.
• Update project.
• Migrate.
• Delete bookends and all previous migrations.
• Delete records from migrations table.

The first bookend renames the affected tables. The second bookend copies the data from the renamed tables to the fresh tables, then deletes the renamed tables.

Note: You can do whatever you like inside the bookends, this is just a minimum.

So, let's say you something like the following for migrations:

• 2017_09_05_000000_create_some_table.php
• 2017_09_05_000001_add_field_x_to_some_table.php
• 2017_09_05_000002_add_field_y_to_some_table.php
• 2017_09_05_000003_add_field_z_to_some_table.php

We would create another migration:

• 2017_09_05_000004_pre_refresh.php

We would create another migration based on the knowledge we have now:

• 2017_09_05_000005_create_some_table.php

We would create the last bookend, where data migration will occur:

• 2017_09_05_000006_post_refresh.php

The first four migrations will not be run because they already have been.

/** 2017_09_05_000004_pre_refresh.php */
class PreRefresh extends Migration
{
    public function up()
    {
        $prefix = 'zz_';
        $tablesToRename = [
            'foos',
            'bars'
        ];

        foreach($tablesToRename as $table) {
            Schema::rename($table, $prefix . $table);
        }
    }
}

No need for a down, because this is a one shot deal. This will run first, which should result in all the tables listed in the array being renamed. Then the consolidated (optimized) migration(s) will run.

/** 2017_09_05_000006_post_refresh.php */
class PostRefresh extends Migration
{
    public function up()
    {
        // Do what you need to do.
        // If you cannot use your models, just use DB::table() commands.

        $foos = DB::table('zz_foos')->get();
        foreach ($foos as $foo) {
            DB::table('foo')->insert([
                    'id'         => $foo->id,
                    'created_at' => $foo->created_at,
                    'updated_at' => $foo->updated_at
                ]);
        }

        $bars = DB::table('zz_bars')->get();
        foreach ($bars as $bar) {
            DB::table('bar')->insert([
                    'id'         => $bar->id,
                    'created_at' => $bar->created_at,
                    'updated_at' => $bar->updated_at,
                    'foo_id'     => $bar->foo_id
                ]);
        }

        // Tear down.
        $prefix = 'zz_';
        $tablesToRename = [
            'foo',
            'bar'
        ];

        foreach ($tablesToRename as $table) {
            DB::statement('SET FOREIGN_KEY_CHECKS=0');
            Schema::dropIfExists($prefix . $table);
            DB::statement('SET FOREIGN_KEY_CHECKS=1');
        }
    }
}

After running this, you can delete all your migrations from the pre_refresh and prior. As well as the post_refresh. Then you can head into the migrations table and delete the entries for those migrations.

Deleting the entries isn't entirely necessary, but if you migrate:rollback you will get error messages stating that the migration can't be found.

Caveats

1. If the architecture isn't modular by design, it can be quite cumbersome. However, if you have separated your code into services it does appear to be a little easier.
2. Laravel error handling and messages during migrations are very limited; so, debugging could be difficult.
3. Highly recommend starting with the most stable tables in your app/service. Further, starting with those that are foundational to your app might also prove beneficial.

Note: When I actually do this in production, not just my local (over and over again), and if there is not a better answer, then I will accept this.

Considerations

If you are breaking your application into service providers with discreet migrations, then you can comment out the service provider in /config/app when you run the migrations. This way you create a batch for the now baselined service. So, let's say you have the following migrations where each letter represents a migration, and each duplicate letter represents the same service:

• A
• B
• C
• A
• C
• B
• A

After consolidating service A:

• B
• C
• C
• B
• A

After consolidating B:

• C
• C
• A
• B

After consolidating C:

• A
• B
• C

update

54 migrations down to 27 so far. I even pulled out some Schema changes from large up() and down() methods and make them separate migrations. The nice side-effect here is the batches. I migrated starting with the base tables upon which everything else is supported; therefore, rolling back is more service by service.

You should create a new migration using command:

php artisan make:migration update_error_message_in_log_for_user_table

Then, in that created migration class, add this line, using the change method like this:

class UpdateLogForUserTable extends Migration
{
    public function up()
    {
        Schema::table('log_for_user', function (Blueprint $table) {
            $table->string('error_message')->nullable()->change();
        });
    }

    public function down()
    {
        Schema::table('log_for_user', function (Blueprint $table) {
            $table->string('error_message')->change();
        });
    }
}

To make these changes and run the migration, use the command:

php artisan migrate

and to rollback the changes, use the command:

php artisan migrate:rollback

You may rollback a limited number of migrations by providing the step option to the rollback command. For example, the following command will rollback the last five migrations:

php artisan migrate:rollback --step=5

See more about Modifying columns with Migration