Migration creation in Laravel - Step-by-Step Execution

Concept Flow - Migration creation

Run artisan command

↓

Create migration file

↓

Open migration file

↓

Define schema in up()

↓

Define rollback in down()

↓

Run migration

↓

Database updated

The flow shows how running a command creates a migration file, then you define the table schema, and finally run the migration to update the database.

Execution Sample

Laravel

php artisan make:migration create_users_table

// In migration file:
public function up() {
  Schema::create('users', function($table) {
    $table->id();
  });
}

public function down() {
  Schema::dropIfExists('users');
}

This code creates a migration file for a users table, defines the table with an id column, and defines how to drop it on rollback.

Execution Table

Step	Action	File Created/Modified	Schema Method Called	Database State
1	Run artisan make:migration create_users_table	database/migrations/xxxx_xx_xx_xxxxxx_create_users_table.php	None	No users table
2	Open migration file	database/migrations/xxxx_xx_xx_xxxxxx_create_users_table.php	None	No users table
3	Define up() method with Schema::create('users')	database/migrations/xxxx_xx_xx_xxxxxx_create_users_table.php	create('users') with id column	No users table yet
4	Define down() method with Schema::dropIfExists('users')	database/migrations/xxxx_xx_xx_xxxxxx_create_users_table.php	dropIfExists('users')	No users table yet
5	Run php artisan migrate	No file change	create('users') executed	Users table created in database
6	Migration complete	No file change	Migration applied	Users table exists

💡 Migration applied successfully, users table created in database

Variable Tracker

Variable	Start	After Step 3	After Step 5	Final
Migration File	Not created	Created with up() and down()	No change	Exists with schema methods
Database users table	Does not exist	Does not exist	Created	Exists

Key Moments - 2 Insights

Why doesn't the users table appear in the database right after creating the migration file?

Because the migration file only defines the schema but does not run it. The table is created only after running 'php artisan migrate' as shown in steps 3 and 5 in the execution_table.

What is the purpose of the down() method in the migration file?

The down() method defines how to undo the migration, usually by dropping the table. This allows rollback if needed, as shown in step 4 where dropIfExists('users') is defined.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the users table actually created in the database?

A Step 3

B Step 5

C Step 2

D Step 1

💡 Hint

Check the 'Database State' column in the execution_table rows.

According to the variable tracker, what is the state of the migration file after step 3?

A Not created

B Deleted

C Created with up() and down() methods

D Empty file

💡 Hint

Look at the 'Migration File' row in variable_tracker after step 3.

If you forgot to define the down() method, what would happen when you try to rollback the migration?

A Rollback would fail or not drop the table properly

B Rollback would succeed and drop the table

C Migration would not run at all

D Database would be deleted

💡 Hint

Recall the purpose of down() method explained in key_moments and step 4 in execution_table.

Concept Snapshot

Migration creation in Laravel:
- Run 'php artisan make:migration name'
- Edit migration file: define up() to create table
- Define down() to drop table
- Run 'php artisan migrate' to apply
- Use 'php artisan migrate:rollback' to undo
Migrations manage database schema changes safely.

Full Transcript

Migration creation in Laravel starts by running the artisan command to create a migration file. This file contains two methods: up() to define the schema changes like creating a table, and down() to define how to undo those changes. The migration file itself does not change the database until you run 'php artisan migrate', which applies the schema changes and creates the table. The down() method allows rolling back the migration safely. This process helps manage database structure changes step-by-step.

Practice

1. What is the primary purpose of a migration in Laravel?

easy

A. To create and modify database tables in a structured way

B. To handle user authentication

C. To manage routes in the application

D. To compile CSS and JavaScript assets

Solution

1. Step 1: Understand migration role

   Migrations are designed to manage database schema changes safely and consistently.

2. Step 2: Compare with other options

   Options A, C, and D relate to authentication, routing, and asset compilation, which are not migration tasks.

3. Final Answer:

   To create and modify database tables in a structured way -> Option A

4. Quick Check:

   Migration = Manage database tables [OK]

Hint: Migrations always deal with database tables [OK]

Common Mistakes:

• Confusing migrations with routing or authentication
• Thinking migrations compile assets
• Assuming migrations handle user sessions

2. Which command correctly creates a new migration file in Laravel?

easy

A. php artisan migration:create users

B. php artisan make:migration create_users_table

C. php artisan new:migration users_table

D. php artisan create:migration users

Solution

1. Step 1: Recall Laravel migration command

   The correct command to create a migration is php artisan make:migration followed by the migration name.

2. Step 2: Check each option

   Only php artisan make:migration create_users_table uses the correct syntax and command name.

3. Final Answer:

   php artisan make:migration create_users_table -> Option B

4. Quick Check:

   Use 'make:migration' to create migrations [OK]

Hint: Use 'make:migration' command to create migrations [OK]

Common Mistakes:

• Using wrong artisan command names
• Omitting 'make:' prefix
• Confusing migration creation with other artisan commands

3. Given this migration snippet, what will happen when running php artisan migrate?

public function up()
{
    Schema::create('posts', function (Blueprint $table) {
        $table->id();
        $table->string('title');
        $table->text('content');
        $table->timestamps();
    });
}

medium

A. Updates the 'posts' table by adding new columns

B. Deletes the 'posts' table if it exists

C. Creates a 'posts' table with id, title, content, and timestamps columns

D. Throws an error because 'timestamps' is not a valid method

Solution

1. Step 1: Analyze the up() method

   The code uses Schema::create to make a new table named 'posts' with columns: id, title, content, and timestamps.

2. Step 2: Understand Laravel Schema methods

   $table->timestamps() adds created_at and updated_at columns automatically. This is valid and common.

3. Final Answer:

   Creates a 'posts' table with id, title, content, and timestamps columns -> Option C

4. Quick Check:

   Schema::create + columns = new table [OK]

Hint: Schema::create builds new tables with specified columns [OK]

Common Mistakes:

• Thinking timestamps() is invalid
• Confusing create with update
• Assuming it deletes tables

4. Identify the error in this migration code:

public function up()
{
    Schema::create('comments', function (Blueprint $table) {
        $table->increments('id');
        $table->string('text');
        $table->timestamps;
    });
}

medium

A. String column 'text' must have a length specified

B. Using increments instead of id method

C. Table name should be singular, not plural

D. Missing parentheses after timestamps method call

Solution

1. Step 1: Check method calls in migration

   $table->timestamps is missing parentheses. It should be $table->timestamps() to call the method.

2. Step 2: Validate other parts

   Using increments('id') is valid, plural table names are allowed, and string columns default length is 255 if not specified.

3. Final Answer:

   Missing parentheses after timestamps method call -> Option D

4. Quick Check:

   Method calls need parentheses () [OK]

Hint: Always add () when calling migration methods [OK]

Common Mistakes:

• Forgetting parentheses on method calls
• Thinking increments is invalid
• Believing table names must be singular

5. You want to create a migration that adds a nullable 'bio' text column to the existing 'users' table. Which up() method code is correct?

hard

A. Schema::table('users', function (Blueprint $table) {
$table->text('bio')->nullable();
});

B. Schema::create('users', function (Blueprint $table) {
$table->text('bio')->nullable();
});

C. Schema::modify('users', function (Blueprint $table) {
$table->text('bio')->nullable();
});

D. Schema::addColumn('users', 'bio', 'text')->nullable();

Solution

1. Step 1: Understand how to modify existing tables

   To add a column to an existing table, use Schema::table with a closure defining the new column.

2. Step 2: Evaluate each option

   Schema::table('users', function (Blueprint $table) { $table->text('bio')->nullable(); }); correctly uses Schema::table and adds a nullable text column. Schema::create('users', function (Blueprint $table) { $table->text('bio')->nullable(); }); tries to create a new table, which is wrong. Options A and D use invalid Schema methods.

3. Final Answer:

   Schema::table('users', function (Blueprint $table) { $table->text('bio')->nullable(); }); -> Option A

4. Quick Check:

   Use Schema::table to add columns [OK]

Hint: Use Schema::table to change existing tables [OK]

Common Mistakes:

• Using Schema::create instead of Schema::table
• Using non-existent Schema methods
• Forgetting nullable() for optional columns