Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi,
My migration process fails, as in all the tables I created before today are being migrated. The table I created today fails to migrate. I do get an error thrown :
Illuminate\Database\QueryException
SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'articles' already exists (SQL: create table articles (id bigint unsigned not null auto_increment primary key, user_id bigint unsigned not null, title varchar(255) not null, excerpt text not null, body varchar(255) not null, created_at timestamp null, updated_at timestamp null) default character set utf8mb4 collate 'utf8mb4_unicode_ci')
This seems to refer to a table that does migrate, but I'm not getting why that error is getting thrown now...
In my migrations folder the create table file (for the missing table) is as follows :
public function up()
{
Schema::create('tags', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('name')->unique();
$table->timestamps();
});
// Article_tag (pivot table)
Schema::create('article_tag', function (Blueprint $table) {
$table->bigIncrements('id');
$table->unsignedBigInteger('article_id');
$table->unsignedBigInteger('tag_id');
$table->timestamps();
//avoid duplicates
$table->unique(['article_id', 'tag_id']);
//set up foreign keys
$table->foreign('article_id')->references('id')->on('articles')->onDelete('cascade');
$table->foreign('tag_id')->references('id')->on('tags')->onDelete('cascade');
});
}
In the Article Model I created a manytomany relationship by :
public function tags(){
return $this->belongsToMany(Tag::class);
}
Anyone can steer me in the right direction?
@gillesdeb what command did you run to migrate your tables?
if you are doing
php artisan migrate:refresh
then you may have an issue with a rollback for your articles table. The rollback should drop the table.
in dev, I tend to run
php artisan migrate:fresh
which ignores the rollbacks, drops the tables and then runs the migrations like they are run for the first time.
@automica first try i ran
php artisan migrate
As that did not go to plan, I tried
php artisan migrate:fresh
This resulted in all tables dropped and migrations created successfully. However:
in the list of migrated tables the table (tags_table) is not being migrated...
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated: 2014_10_12_000000_create_users_table (15.27ms)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated: 2014_10_12_100000_create_password_resets_table (14.35ms)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated: 2019_08_19_000000_create_failed_jobs_table (15.38ms)
Migrating: 2020_09_26_141602_create_posts_table
Migrated: 2020_09_26_141602_create_posts_table (8.91ms)
Migrating: 2020_09_26_142800_create_projects_table
Migrated: 2020_09_26_142800_create_projects_table (6.12ms)
Migrating: 2020_09_26_142926_create_assignments_table
Migrated: 2020_09_26_142926_create_assignments_table (6.69ms)
Migrating: 2020_09_28_113244_create_articles_table
And I get the error as in my original posts.
After I tried running the command
php artisan migrate:rollback
followed by
php artisan migrate
Migrating: 2020_09_28_113244_create_articles_table
Migration failed almost instantly got the error (sqlstate 42501)as above. it seems to get stuck or something over the same table... (which worked fine before, so not really understanding why it gives me an error now)
After I tried :
php artisan migrate:refresh
Seems like it was going well :
Rolling back: 2020_09_26_142926_create_assignments_table
Rolled back: 2020_09_26_142926_create_assignments_table (7.09ms)
Rolling back: 2020_09_26_142800_create_projects_table
Rolled back: 2020_09_26_142800_create_projects_table (1.32ms)
Rolling back: 2020_09_26_141602_create_posts_table
Rolled back: 2020_09_26_141602_create_posts_table (1.96ms)
Rolling back: 2019_08_19_000000_create_failed_jobs_table
Rolled back: 2019_08_19_000000_create_failed_jobs_table (5.01ms)
Rolling back: 2014_10_12_100000_create_password_resets_table
Rolled back: 2014_10_12_100000_create_password_resets_table (4.83ms)
Rolling back: 2014_10_12_000000_create_users_table
Rolled back: 2014_10_12_000000_create_users_table (4.53ms)
Migrating: 2014_10_12_000000_create_users_table
Migrated: 2014_10_12_000000_create_users_table (15.70ms)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated: 2014_10_12_100000_create_password_resets_table (14.85ms)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated: 2019_08_19_000000_create_failed_jobs_table (16.07ms)
Migrating: 2020_09_26_141602_create_posts_table
Migrated: 2020_09_26_141602_create_posts_table (6.54ms)
Migrating: 2020_09_26_142800_create_projects_table
Migrated: 2020_09_26_142800_create_projects_table (12.22ms)
Migrating: 2020_09_26_142926_create_assignments_table
Migrated: 2020_09_26_142926_create_assignments_table (9.88ms)
Migrating: 2020_09_28_113244_create_articles_table
But ended up with same sqlstate error
I thought maybe to try and give a path :-) but that command did not exist...
php artisan migrate --path:/database/migrations/2020_10_01_103530_create_tags_table.php
has the tags migration got the correct namespace and class name?
Show the migration please. And try dumping autoload
composer dump-autoload
@automica Yes, quite sure about that:
Models>Tag.php
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
class Tag extends Model
{
use HasFactory;
}
Migrations>create-tags-table.php
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class CreateTagsTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('tags', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('name')->unique();
$table->timestamps();
});
// Article_tag (pivot table)
Schema::create('article_tag', function (Blueprint $table) {
$table->bigIncrements('id');
$table->unsignedBigInteger('article_id');
$table->unsignedBigInteger('tag_id');
$table->timestamps();
//avoid duplicates
$table->unique(['article_id', 'tag_id']);
//set up foreign keys
$table->foreign('article_id')->references('id')->on('articles')->onDelete('cascade');
$table->foreign('tag_id')->references('id')->on('tags')->onDelete('cascade');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('tags');
}
}
Try giving it its own migration, instead of adding it to the tags migration :)
@sinnbeck héhé that worked but how come I can't do it at once (as shown in the tutorial)?
Not sure why. But be aware that you only get one migration if it is one file, and that you need to drop both tables in down
@gillesdeb your down method wasn't dropping the join table 'article_tag' so your key constraints were getting upset.
add
public function down()
{
Schema::dropIfExists('tags');
Schema::dropIfExists('article_tag');
}
Ooh, so i only had to add
'Schema::dropIfExists('article_tag');'
? Didn't realise it was necessary to do this from the start, makes sense to reverse the migration..
I've separated them and it worked like a charm (down method filled in automatically).
Tried your suggestion, now it works like a charm too!
Please or to participate in this conversation.