Laravel migration table created correctly but contact_list table returns an empty set

Question

So, I am using Laravel 10.32.1, and I'm trying to migrate my laravel migration tables to my MariaDB server, and while the migration process does work, and the contact_list table does get created, instead of the expected result, which would have resulted on the tables being populated with columns like this, (note that this is a partial mock up of contact_list table if they have actually worked, i couldn't fit the rest because width constraints)

+----+------------+-----------+---------------+--------------+------+---------+-------+------------+-
| id | first_name | last_name | email_address | phone_number | note | address | photo | timestamps |                             
+----+------------+-----------+---------------+--------------+------+---------+-------+------------+-

instead I got

Empty set (0.070 sec)

. How could contact_list table returns an empty set instead of the expected table column above?

I tried doing sudo php artisan migrate:fresh (yeah I have to use sudo, I accidentally installed MariaDB as root, also I'm using Ubuntu 22.04 on WSL), which deletes all the existing tables in my contact database and runs the migrate command all over again, but, after running the command, then enter MariaDB contact database, and run select * from contact_list I still got this problem:

MariaDB [contact]> select * from contact_list;
Empty set (0.070 sec)

Then I tried to see if other migrations are suffering from this problem too, so I tried select * from users and surprise! It also spits out the exact same message:

MariaDB [contact]> select * from users;
Empty set (0.007 sec)

This is what's inside my contact database by the way:

MariaDB [contact]> show tables;
+------------------------+
| Tables_in_contact      |
+------------------------+
| contact_list           |
| failed_jobs            |
| migrations             |
| password_reset_tokens  |
| personal_access_tokens |
| users                  |
+------------------------+
6 rows in set (0.001 sec)

It feels kinda weird since both 2014_10_12_000000_create_users_table.php and 2023_11_20_054223_create_contact_table.php both has codes to create said tables.

2014_10_12_000000_create_users_table.php:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

use function Laravel\Prompts\table;

return new class extends Migration
{
public function up(): void
    {
        Schema::create('users', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }
public function down(): void
    {
        Schema::dropIfExists('users');
    }
};

2023_11_20_054223_create_contact_table.php:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

use function Laravel\Prompts\table;

return new class extends Migration
{
public function up(): void
    {
        Schema::create('contact_list', function (Blueprint $table) {
            $table->id();
            $table->string('first_name',24);
            $table->string('last_name',24);
            $table->string('email_address'); 
            $table->string('phone_number',16);
            $table->string('note',200);
            $table->string('address',50);
            $table->string('photo',100);
            $table->timestamps();
            $table->softDeletes();
        });
    }
public function down(): void
    {
        Schema::dropIfExists('contact_list');
    }
};

After all of these, I tried searching for answers on Stack Overflow, but many of these questions are old Laravel v5.x questions. And it feels like there is something wrong with either my database or my migration scheme. I don't know, it just feels unsolveable to me.

Answer 1

It looks like you are combining the tasks of migrating and seeding into one concept.

A migration (generally) is only responsible for creating or updating a database scheme and structure, not for populating data.

Populating data is (generally) performed through seeding.

When working locally, the distinction may seem unimportant, but having migrations separate from seeding is useful for when you want to have different default data for your local environment, from your test environment, from your production environment.