Migration using wrong foreign key constraints when utilizing custom table names

[nathanmal]

How to reproduce

1. Have an existing table named 'taxonomies'
2. Update the taxonomy config file to use a different table name (ie 'categories')
3. Run migration

When adding child taxonomies, such as if you're migrating taxonomies from the old table to the new one, it may produce a database error because the foreign key constraint fails

Expected Behavior

The foreign key constraints should reference the custom table

Solution

In the current migration the constraint is using a hard-coded table name

$table->foreignId('parent_id')->nullable()->constrained('taxonomies');

It should be updated to

$table->foreignId('parent_id')->nullable()->constrained($tableNames['taxonomies']);

Additionally, I presume the taxonomables table should also specify the constraint

$table->foreignId('taxonomy_id')->constrained()->cascadeOnDelete();

should be updated to

$table->foreignId('taxonomy_id')->constrained($tableNames['taxonomies'])->cascadeOnDelete();

[aliziodev]

Thanks for reporting this issue and for the clear explanation!

You're absolutely right — the current migration uses a hard-coded table name (taxonomies) in the foreign key constraints, which causes issues when customizing the table name via the configuration.

I'll update the migration in the next release so that it dynamically references the configured table name, as you suggested

Thanks again for catching this — it’ll be included in the upcoming release. 👍