Migration creation in Laravel - Practice Problems & Coding Challenges

Challenge - 5 Problems

📝 Syntax

intermediate

Correct Laravel migration syntax for creating a table

Which option correctly creates a migration to make a users table with an id and email column?

A Schema::make('users', function (Blueprint $table) { $table->id(); $table->string('email'); });

B Schema::create('users', function (Blueprint $table) { $table->integer('id'); $table->string('email'); });

C Schema::create('users', function (Blueprint $table) { $table->id(); $table->string('email'); $table->timestamps(); });

D Schema::create('users', function (Blueprint $table) { $table->id; $table->string('email'); });

💡 Hint

Remember the method to create tables is Schema::create and $table->id() adds an auto-incrementing ID.

Option C uses the correct Schema::create method and calls $table->id() as a method, which creates an auto-incrementing primary key. Option C uses a non-existent make method. Option C uses integer('id') which does not set the primary key or auto-increment. Option C misses parentheses on $table->id, causing a syntax error.

❓ component_behavior

intermediate

Effect of nullable() in Laravel migration columns

What is the effect of adding ->nullable() to a column in a Laravel migration?

A The column will have a default empty string value.

B The column allows NULL values in the database.

C The column becomes a primary key.

D The column is automatically indexed.

💡 Hint

Think about what NULL means in databases.

Adding ->nullable() means the column can store NULL values, which means it can be empty. It does not set default values, primary keys, or indexes.

❓ state_output

advanced

Result of running a Laravel migration with a foreign key constraint

Given this migration snippet, what happens when you run it?

Schema::create('posts', function (Blueprint $table) {
  $table->id();
  $table->foreignId('user_id')->constrained()->onDelete('cascade');
  $table->string('title');
  $table->timestamps();
});

A Creates a posts table with a user_id column linked to users.id, deleting posts if the user is deleted.

B Creates a posts table with a user_id column but no foreign key constraint.

C Throws an error because <code>constrained()</code> requires a table name argument.

D Creates a posts table but the user_id column is nullable by default.

💡 Hint

The constrained() method automatically links to the users table by convention.

Option A is correct because foreignId('user_id')->constrained() creates a foreign key to the users table's id column by default. The onDelete('cascade') means if a user is deleted, their posts are deleted too. Option A misses the constraint. Option A is wrong because the table name is optional if it follows Laravel conventions. Option A is wrong because the column is not nullable unless specified.

🔧 Debug

advanced

Identify the error in this Laravel migration code

What error will this migration code cause when running php artisan migrate?

Schema::create('comments', function (Blueprint $table) {
  $table->id();
  $table->string('content');
  $table->foreignId('post_id')->constrained('posts');
  $table->timestamps();
  $table->foreign('post_id')->references('id')->on('posts');
});

A Error: Duplicate foreign key definition on 'post_id'.

B Error: Missing primary key definition.

C No error, migration runs successfully.

D Error: 'constrained' method requires no arguments.

💡 Hint

Check how foreign keys are defined and avoid repeating them.

The code defines a foreign key twice on the same column: once with foreignId('post_id')->constrained('posts') and again with foreign('post_id')->references('id')->on('posts'). This causes a duplicate foreign key error. Option A is wrong because $table->id() defines the primary key. Option A is wrong because constrained() can take a table name argument. Option A is incorrect because the migration will fail.

🧠 Conceptual

expert

Understanding Laravel migration rollback behavior

After running multiple migrations, you execute php artisan migrate:rollback. What exactly happens?

A No changes happen unless you specify the number of steps to rollback.

B All migrations are reversed, returning the database to its initial empty state.

C Only the very last migration file is reversed, regardless of batch size.

D Only the last batch of migrations applied is reversed (tables dropped or columns removed).

💡 Hint

Think about how Laravel groups migrations into batches.

Laravel groups migrations into batches when running them. The rollback command reverses the last batch of migrations, not all migrations or just one file. Option D is incorrect because it would require multiple rollbacks. Option D is wrong because rollback works by batch, not single file. Option D is wrong because rollback defaults to one batch if no steps specified.

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