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.