How to Do a Migration in Laravel 5.5

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();
    });

Migration laravel 5.5 : cannot create table except users table and password_reset table

The migration files need to be migrated in right order. You can't migrate a table with a non existing foreign key.

You probably have a foreign key in some migration and the id key for that will come to existence later in the next migration file. That is why you get this error.

Check your migration files and watch out on order they get created.

For example if you have a foreign key alats_merk_id_foreign then the migration file with alats_merk_id must be migrated before.

Laravel 5.5 set size of integer fields in migration file

You can't do this, but you can use different types of integer:

$table->bigInteger()
$table->mediumInteger()
$table->integer()
$table->smallInteger()
$table->tinyInteger()

https://laravel.com/docs/5.5/migrations#columns

Laravel 5.5 unable to do initial migrate

May be you need to install PHPs PDO MySQL support to your server/dev machine.

Look at your phpinfo() for PDO MySQL driver info. IF doesnt exists install the driver.

If your server/dev-machine is ubuntu and your php version is 7.0 try to install with apt-get install like this

sudo apt-get install php7.0-mysql

You can use the MySQL PDO driver with a MariaDB database

Using Laravel 5.5 how do I duplicate a column in a table with a migration?

You can use DB::raw() to force Sql to use another column instead of a string value.

Season::withTrashed()
    ->update([
        'uploader_channel_partner_id' => DB::raw('`channel_partner_id`'),
    ]);

Laravel 5.5 Consolidate migrations w/ production database

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

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.
Laravel error handling and messages during migrations are very limited; so, debugging could be difficult.
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:

After consolidating service A:

After consolidating B:

After consolidating 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.